Re: [Alephmodular-devel] On integrating preferences...

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

I've made progress. Within preferences.cpp I created a 
PreferencesCollection class that's local to AM. One version is referred 
to as runtime_preferences and is generally accessed at runtime through 
constant pointers to its internals. Changes to values within are done 
through other calls.

The preferences dialog gets another fresh PreferencesCollection called 
dialog_preferences which is used during the dialogs, then either 
applied to the CPreferences repository (and a new runtime preferences 
object created and reinitialized) or is purely disposed.

These changes are checked in and operational on the pref-development 
branch. I'm going to smooth out some of the changes. Also, I can 
finally start tweaking some of the AM-side preference objects now that 
they are decoupled from the external values. Most notably is existing 
use internal to the runtime preferences of GDSpec and FSSpec.

Some related changes relating to how a CFileDesc is supposed to pass 
platform specific info to CPreferences and back again is also 
warranted.

I'm a bit unhappy with all the casts around usage of get_value type 
preference calls. And so may need to smooth out CPreferences related 
external and internal APIs for that.

I'm getting nearer and nearer to the point where I can create a 
CPreferencesReader/Writer_PList element. At this point I haven't 
decided on an XML parsing library. Nor have I decided on how I want to 
integrate such external libraries into the project. Do I set things up 
like libspeex and liblua for A1 or what?

-Jeremy Parsons

On Dec 9, 2003, at 6:05 PM, Br'fin wrote:

> Still mulling over the preferences. But here's some updates and 
> thinking.
>
> Looking into MVC type details led me to the Model-View-Controller song 
> performed by Jack Dempsey at the 2003 Apple WWDC.
> http://www.oreillynet.com/pub/wlg/3533
>
> This may be instructional regardless of what I do with the preferences 
> GUI. I'm trying to balance the gui customization versus what general 
> platform-neutral support I can muster.
>
> My current plan is to setup a class to hold all of the runtime 
> preferences. A sibling of this instance will be created and either 
> man-handled or abandoned by the preferences GUI. If the changes are 
> ok'd, then all the info will be dumped into the CPreferences API and 
> flushed to disk.
>
> The current code will continue to use the in memory preference 
> structures, but will be given const pointers instead of flexible 
> ones... the values of these preferences can only be changed 
> functionally, direct access to the properties is read-only. This 
> shouldn't be so much of a hassle, and it will help root out the few 
> places in code that do preferences changes while the game is playing 
> (For instance view option changes and volume changes.)
>
> After AM is running off new preferences runtime, then I'll try and get 
> the preferences GUI functioning again.
>
> -Jeremy Parsons
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Alephmodular-devel mailing list
> Ale...@li...
> https://lists.sourceforge.net/lists/listinfo/alephmodular-devel
>