Re: large commit

Kristian G. Kvilekval wrote:
> The prefs.def should make it easier, but your point that
> there are plugin variables creeping into the main tree
> is valid.   
> 
> One thing that has always bothered me was that to understand what a
> plugin does, we need to load it (slowing down the startup). For
> example, to the know that vorbislmc processes ogg files, we load the
> plugin and call GetExtensions  on it.  
> 
> In order to separate the plugins form the core code, I would think we
> need a plugin descriptor file.  This would be loaded on main program
> startup and then load the plugin on demand when really needed.   The
> file could also describe plugin variables.

why would we need the player to know about plugin variables? All we need 
to know is which extensions we support when we startup.

If you mean configuration variables in the main player for a plugin. 
The only way we'd be able to solve something like this is to keep the 
configuration variables part of the plugin, change the way we do our 
preferences so that we can say, right click on a plugin name in a list 
and select properties, a window opens up which generates a configuration 
  table by querying a vector map of the plugin's config variables.  The 
values for these variables aren't stored in the plugin, merely the names 
of the variables.  This way the preference class still controls 
preferences the way it normally would, it's just using a vector map of 
strings instead of const strings and such that it uses now.

in summary,  on startup it would query each plugin in the plugins 
directory for extensions, preference variable names, and type (we use 
extensions to do that now). The preference class now has an extended 
list of preference variables it can query and save from the preference 
file. Thus, the preference class's ownership over preferences remains 
and we dont need separate files to handle things.  Also, we could make 
the UI extremely extensible by having a dynamic options panel for plugin 
settings.  This means we can know tell what plugins we have and we dont 
need  to recompile to add new ones.

so yea, i vote for a mapped vector of strings.  one set of strings is a 
list of valid variable names. The second set of strings is for 
identification.  something like   pluginname::this is what i do. for 
aiding dynamic generation of options menus in UI's.  We can query for 
prefs from plugin name and grab the  description and value and generate 
options screens for them.  A second call method would be made at boot to 
retrieve a mapped list of default values and the variable names they 
goto.  This would also be submitted to the prefs class.

preferences wouldn't just be anywhere for people worried that this would 
move preference definitions all over zinf.  Preferences would be defined 
in the header of the main class as private data to that class. The 
player's prefs would be defined in the pref class itself.

oh yes i like this idea a whole lot.  Something to look forward to in 2.3


> Look at the current prefs.def in base/include.  You may define a tag
> ZINF_PREF(PluginTag, "default string")
> 
> In the plugin you can call
> 
>  string v;
>  m_pContext->prefs->GetPrefString(kPluginTagPref, v);
> 
> 
> 
> On Mon, 2003-03-17 at 14:46, Robert Hart wrote:
> 
>>On Sat, 2003-03-15 at 09:37, Kristian Kvilekval wrote:
>>
>>
>>>My "preference" would be for a more structured preference file that
>>>could be used as a default preferences, current preferences, and also
>>>be used to generate the gtk option pane or even ncurses pane, etc. 
>>>However this seemed to be a nice way to get rid of "declare preference
>>>in a file , declare default in another place" problem.  Not that I am
>>>totally enamored of it.  Shouldn't have an effect on the rest of the
>>>programmers.   If I hear a lot of "boos",   we can ditch it.
>>
>>I think for plugins to be true plugins, you need to be able to write one
>>without changin any existing zinf code. When I tried to write my own
>>plugin a few weeks ago, I got stuck on how to add preferences to it.
>>
>>AFAICT you can't without editing zinf proper, and even then it's not
>>obvious what to do.
>>
>>Rob
>>



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en