I have a few reservations about how the properties functionality seems
to be set up.
On the scheme side, the code seems overly gnome-centric, since actual
gnome pointers are being sent across, although I guess this could be
generalized to include other ui's.
On the gnome side, the dialog doesn't obey the proper semantics for
a gnome property box. First, the 'properties' being set by a gnome
property box should only be changed when the user clicks 'ok' or
'apply', and then only if options have changed. The 'close' button
doesn't really have cancel semantics, as there is nothing to cancel.
Currently however, boolean options are changed as soon as the user
toggles them.
I would like to change the way the options dialog works in gnome.
Specifically, it should:
1. Allow the user to change the options in the 'upper' part
of the dialog, without setting them, but perhaps validating
them using a scheme callback.
2. Keep a list of the 'changed' items and, when the user
clicks 'ok' or 'apply', tell scheme to change them.
I think the ui should only tell scheme to change items
that the ui has validated. This allows the ui to control
when 'error' messages are shown.
Also, I think the scheme code presumes too much about how options will
be displayed by the ui (pages, etc.) Different ui's may have different
idioms for setting preferences, and the guile side shouldn't need to
know anything about it. I don't think the guile side should be
handling ui pointers/ objects at all. Instead, I think the guile side
should send the ui the list of preferences, including the information:
+ Option name
+ Option category
+ type
+ short hint
+ long documentation
+ value getter and default value getter
+ value validator
+ value setter
Then, the ui can decide how best to display the preferences and allow
the user to change them in that ui's idiom. The guile side wouldn't
need to have ui pointers at all.
comments?
dave
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
