I'll change the code accordingly
> [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)
easy enough
> [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 :-)
>
With pleasure. now I can stop looking for methods to change whatever i need.
I will be adding a toggleSpellingListener( ... ) function to work with the
AV_View class
> [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.
Good idea, but do we actually need to nuke other schemes? The reason why I'm
asking is because we could add some nice advanced functionality of allowing
the user to select which scheme to use. That way, he can save multiply
preferences and can switch back and forth rather quickly.
> [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....
I'm not sure which persistent it should be inherited from. To remember which
tab was last set, app-persistent, but to remember any of the data, it should
be frame-per. But, on the other hand, since I'll have to be loading the
frame's data from the Pref's each time I run (independent of which frame was
last loaded, etc) because some of the preferences might change, like via a
menu or toolbar.
Therefore, I guess app-persistent then.
> 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....
>
That should not be very hard to implement the save button. I don't see any
problems with the autosave feature. Granted, I don't know the internals, and
if there is a 'dirty' flag or anything.
One problem that I see is with saving the auto-save bit. If they choose to
turn off the auto-save bit, it should write that bit out to the preference
file, but not any of the other changes.
How would/could we do that? Load the prefs, change the autosave, then
rewrite.? The problem is if some other prefs were changed (say by the menu)
then we go to the options and turn autosave off. We should save the autosave,
but not the other changes.
Or as it's currently implemented, when you turn off the autosave, that will
not be saved unless you hit the save button.
> (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).
mentioned above. I should read the emails more carefully before replying :>
I will work this into the next update of the dialog (i.e., the next patch
mailing)
> ===================================================================
>
> 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.
>
All add some of that to XAP_Prefs
addListener
removeListener
startBlockChange()
endBlockChange()
> ===================================================================
>
> 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 ??
>
That should work well. The code as written is just C stuff anyway.
I'll go ahead and add the code under
createAccelerators( GtkWidget * );
> ===================================================================
>
> 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.
this works out will, I'll be on the road during the weekend. :>