PrefsListener API again
Stephen Hack (shack@uiuc.edu)
Tue, 19 Oct 1999 14:31:47 -0500
On Tue, Oct 19, 1999 at 01:05:36PM -0500, Stephen Hack wrote:
> On Tue, Oct 19, 1999 at 11:04:38AM -0500, Jeff Hostetler wrote:
...
> >
> > 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()
>
One problem that I just saw was that sometimes there is a need to know what
the old value was and the new value will be.
On a simular note, how should the listener find out what has changed? Should
it remember itself the old value, or should the prefs be able to tell it
somehow?
One possibility is a hash table of all the keys that have changed. That way,
when each listener is called, it can lookup the key it's interested in in the
hash table to see if it's changed.
example: toggleSpelling() - when the listener is called, it can check in
the hash to see if teh one key that it's interested in has changed
-shack
This archive was generated by hypermail 1.03b2.