===================================================================
i just added getPrefsValueBool() to Prefs and {get,set}ValueBool
to PrefsScheme per your earlier suggestion.
===================================================================
cool dialog !! before we check it in, i'd like to get you to
fix a few things first, if that's ok:
[1] remove all the #if 0'd code from the dialog that was cloned
(the #if 0'd debug blocks are cool and should be kept)
[2] add strings to the string table for each of the dialog static
text fields (see abi/src/wp/ap/xp/ap_String_Id.h) and then
reference them in the various window_title and button_label calls
(this will let us internationalize them quickly)
(see one of the other dialogs for code snippets)
[3] update calls to prefs to use new Bool methods :-)
[4] down with the OK and Cancel buttons, I'd like to have a
"restore factory settings" button -- which would set the
current scheme back to _builtin_ and nuke any other schemes
in memory.
[5] you made the options dialog inherit from non-persistent
rather than app-persistent -- i'm wondering if there it would
be better to do app-persistent -- for example, this would let
it be able to come up the second time on the same tab as was
up when the user closed it the first time....
longer term, i'd also like to have a "save settings" button next
to those 3 buttons -- which would write the current settings to
disk, but i don't know how that would interact with the way we
write the file on exit and the auto-save bit that we carry
around -- this whole area probably needs to be re-thought, so
let's wait not try to do it now....
(paul will veto this one, i'm sure :-) much longer term, i'd like
to see an 'advanced' tab which would let me pick a name for the
'custom' scheme and have a combo box of all the schemes defined.
this way, i could keep track of several schemes -- say, one for
english, one for german, and one for weird testing... and easily
switch between them (like i do now by editing the file).
===================================================================
w/r/t PrefsListener API, i'd vote for simplifying it some -- it's
a very low frequency event (like when the user hits OK on the
new dialog or toggles something from the menu), so i don't think
we need the complicated pattern matching stuff.
i'd suggest a simple "tell me when anything changes" listener
and put the responsibility on the actual listener to query
the values it cares about and do the right thing. that way, the
pref code can just send one message to each listener. and each
listener can be rather simple. [one could probably use the same
words in the last 2 sentences to describe the proposed method :-)
but my assertion is that simpler is better and each listener
should have already internalized the value(s) of the pref keys
that it's interested in and can quickly and easily re-fetch and
compare them and quickly return if there's nothing for it to do.]
we may need to have some kind of suspend-/resume-notifications
method in the prefs, so that the options dialog can set a bunch
of values in a batch and then have one notification go out --
incase setting them individually after the dialog goes down
causes too much flashing.... but we can wait on that.
===================================================================
w/r/t the code to change win32 "&" into gtk "_" on dialogs,
yes it is unfortunate that the class hierarchy goes:
(generic-dialog-->specific-dialog-->specific-platform-dialog)
and not:
(generic-dialog-->generic-platform-dialog-->specific-platform-dialog)
[rather it's unfortunate that we can't inherit both ways at the
same time, because we really need the inheritance the way i have it.]
because this does cause problems for unix which needs to hang
extra (platform-specific but generic) helper functions on each dialog.
shaw has been collecting them in abi/src/af/util/unix/ut_dialogHelper.*
can your new routines be folded into there ??
===================================================================
thanks for the help and suggestions,
jeff
ps. i'll be on the road again until this weekend, so it might
take me a few days for me to reply.