On Mon, 03 Jul 2000, you wrote:
> Kevin Finn writes:
> >
[...]
>
> I think disabling by name would be sufficient - it is consistent with
> the rest of the options interface.
>
> Which brings me to another point - if we make options mutable, should
> it be an error if we try to read a muted option's value? If an
> option is disabled, the option's value is not relevant to
> the current state of gnucash, and code should not be trying to read
> that value. I think, therefore, that it should be an error and
> signalled as such.
Good point. This would require storing a "selectable" boolean with each
option, which might be a waste for the majority of options for which we
won't be doing this kind of stuff. The other alternative would be to query the
widget to determine its current sensitivity to input. I know there is
gtk_widget_set_sensitive(), is there a corresponding function to
get_sensitive() ? Since this information is already stored by Gtk+ somewhere,
I would rather consult its value if possible.
Would it be reasonable to make this error a run-time crash or a popup warning?
I'm not sure how you would return an error from a bad option lookup, since
there could be many different types of options and what might be an error
condition from one would be a valid return value from another (-1 would be a
good error value for a boolean, but not for a numeric range option, etc.).
For every option which is made available/unavailable by another option
(example: a boolean to enable a range option) we could just store the name of
the "parent" option in the enabled/disabled option, and it could query its
parent to find out whether it should return a value, or whether it should
signal an error. It would be nice if we could only use "variably enabled"
options when their selectability is controlled by another option, but I think
there might be cases where we would enable/disable certain options on the basis
of other things, such as whether the user has money in the account or something
like that.
Maybe we could just pass each option an optional parameter which is a callback
function. If the option has such a callback, it can fire that off to determine
if the option is allowed to be queried right now, and can use that to decide
whether to return a value or signal an error. The callback could know to check
the boolean option enabled/disabled flag, or check account balance, etc.
The callback could also be checked if someone tries to set the value - you
couldn't change a disabled option in the GUI but maybe you could try to in a
script/report, so that might come in handy. A "am I enabled?" callback would be
the most comprehensive way to handle this sort of thing, without adding
overhead for options which don't need that complexity.
>
> Please don't take my comments as definitive, though - Dave Peticolas
> wrote most of the options code, and he may have other ideas.
>
Thoughts, Dave?
> ------------------------------------------------------------
> Robert Merkel [EMAIL PROTECTED]
>
> ------------------------------------------------------------
--
Kevin Finn
[EMAIL PROTECTED]
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
