options dialog app persistant?

Stephen Hack (shack@uiuc.edu)
Fri, 29 Oct 1999 00:16:55 -0500


On Tue, Oct 19, 1999 at 11:04:38AM -0500, Jeff Hostetler wrote:
> [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 don't think the options dialog should be persistent. I have been converting
the code to App-persistent and find that there are very few values that should
"persist".

Currently, saving the notebook page number is the only value that I've needed
to keep between options runModal().

One might say argue that I could keep all the perference values, but that
would cause several problems.

* locally stored values must stay consistant with the appropriate values
in the prefs. There are two ways to do this...

(current implementation)
1) set the values of checkbuttons from Prefs during runModal()
(_populateWindowData). Here, there is no need to save any values
in the persistant

or
2) create a pref listener that would update all of the internal
values of ap_Dialog_Options

The second option would allow me to keep my interal list of UT_Bools and
the like consistant, but I would still need to populate the window
controls' data.

* the widget should be created per runModal because of the resource
restrainst of the system. I don't think it would be good to keep all the
widgets allocated for the duration of the application. Because of this,
upon calling runModal, all the control's value must be set.

Getting back to storing the notebookpage number, one solution to for a
non-persistant frame would be to store the value as a preference. This would
store the last used page between instances of AbiWord (I think this is what
word does)

-shack



This archive was generated by hypermail 1.03b2.