On Tue, 04 Jul 2000, Dave Peticolas wrote:
> Robert Graham Merkel writes:
> > Kevin Finn writes:
> > >
[...]
>
> Disabling by name would be just fine. Keep in mind, though, that disabling
> would most often be done in scheme, or at least the information that one
> option's sensitivity depends on another option's value should be stored
> in the scheme option structure. The option GUI code should not know the
> 'meaning' of the options -- it just implements the GUI.
>
That makes sense. I wasn't entirely clear on the distinction between the
responsibilities of the scheme and the top-level.c code, but that clears it up.
> Given that this capability isn't needed for most options, I think it
> would be easiest to implement this using the 'setter' function of the
> boolean option object. I anticipated that boolean options might need
> to be more sophisticated than they are now, which is why I called the
> current boolean option constructor a 'simple-boolean-option' in the
> scheme code. So, I would suggest defining another boolean option
> constructor which allows you to specify a callback to be invoked when
> the option changes its value, and then use that callback to
> disable/enable the other option as appropriate.
>
I don't know if you'd seen the other mail that I sent yesterday, I had sort-of
worked around to the idea of a callback as well. Having a separate
complex-boolean-option makes the whole thing a lot cleaner.
> Kevin, would you like to work on this? It would be mostly scheme work.
> As you point out, changing the sensitivity of a widget is just one
> gtk+ call.
>
Sure, I'll take a look at it over the next few days.
>
> > 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.
>
> I consider an option being editable in the GUI and an option's value
> being irrelevant to be independent concepts, so I don't think this
> situation should necessarily be an error.
>
So the callback from when the boolean is changed might need to change the value
of the no-longer-editable option to a "safe" value? What about the case where
we make an option non-editable due to something besides another option, for
example we disable an option if the account balance is zero or something like
that. Since there's no boolean option to check for whether our non-editable
option is editable or not, do we need to provide a way to query the editable
status of the option? Can we query the Gtk+ "sensitive" status of a widget, or
do we have to store that state?
Kevin Finn
[EMAIL PROTECTED]
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
