[Alephmodular-devel] On integrating preferences...

[Br'fin <br...@ma...>]

Ok, so I have this nifty new preference API... now just how do I 
integrate it into AM?

I'm thinking of leaving the way the code accesses preferences while 
running the same (sound flags and data structures in memory.) Though it 
will need to have initializaers and reinitializers that load the 
preferences values into runtime structures. There's also a few elements 
that change preferences (mostly volume and view size choices)

The other place that uses preferences is the preferences UI. It 
currently does: Change runtime structures and if cancel is chosen it 
reloads from disk. On one hand I don't see anything horribly wrong with 
this, but it's interesting to note that neither the Java nor OSX APIs 
are setup to handle that kind of use. They expect the Preferences to 
hold final decisions, like once you hit the OK button and not the 
transitory choices before that actual point.

I'm thinking of trying to set this up in another way.

One AM side pref_editor class. On creation, it initializes off the 
runtime structures, but has its own copies. On cancel, it does nothing 
but free its own memory. On OK it expresses it's values into the 
preferences API, calls for a flush of the values to disk, and then 
calls for reloading the API values into the runtime ones.

*ponder* I have got to read up on Model-Controller-View details. 
Something in that vein feels like what I'm doing. Though I'm unsure of 
my balance... Model: Preferences. Controller: Pref Editor 
(Cross-platform), View: GUI (Platform specific)

-Jeremy Parsons