Re: New preferences code

Ed Sweetman <[email protected]>
Newsgroups gmane.comp.audio.zinf.devel
Message-ID <[email protected]>
Tim Lesher wrote:
> I'm integrating the new-style preferences code (using ZINF_PREF) in
> the win32 build.  Just as a sanity check, it looks like the k*Pref
> const char* symbols are only defined in the main executable, although
> they're referenced in some of the shared objects.  Are these shared
> objects supposed to be linked with these symbols undefined, and then
> use the instances defined in the main zinf binary?
> 
> Thanks.
> 

it's my understanding that they're linked with the preference object file.


I'd rather see all these const char's removed. Why use a middle man when 
we can just as easily use the string when asking for a preference in 
another object?  Plus, we have plugins that have their own const char 
pref variables instead of them being in the preference.cpp file. It just 
doesn't make sense to use them.

Secondly, I dont think the new preference system adheres to the 
project's goal of being minimal sharing.  Preferences should be taken 
care of within the preference object. That's it.  No worrying about if 
this plugin can access the global data from this or that object. And 
yes, i do remember specific windows issues where the preference value 
was just not being used even though it was in unix.

My solution is pretty simple as outlined in my Todo List.  Plugins 
manage their own preference strings and default values in what will 
likely be a vector map of strings that gets accessed upon plugin loading 
much like the extensions are accessed.  These vector maps are sent 
directly to a method in the preference class that concatenates it to 
it's own master vector map of preferences (starting with core player 
preferences that are kept in the preference class itself).  In this way 
a plugin need not touch anything from the main program to add/remove or 
change preferences dealing with it.  Everytime new preferences are added 
the preference file is re-read and any new valid entries are dealt with. 
This allows extensibility, minimal sharing, data integrity and frees up 
plugin development from the core player.    I also have further plans 
down the road dealing with this involving the gui but that's another topic.







-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.