[vlc-devel] Re: RFC: refurbishing the configuration manager

[Samuel Hocevar]

On Wed, Oct 09, 2002, Gildas Bazin wrote:

> >    b_fullscreen is somewhat particular because it is common to all video
> > output modules, so we could put it in the vout_thread_t struct. The same
> > goes for width and height.
> 
> I don't think this variable is that particular, and one of the good points 
> about including this variable into a dynamic configuration system would be 
> that the framework in place would automatically create a menu in the GUI 
> for the user to activate the option. No need for the interface plugin to 
> handle these details itself.

   Yes I fully agree with you on this. I was saying it was particular
because of the way it was currently handled (it exists whether the vout
module supports fullscreen or not, and the interface directly changes
p_vout->i_changes), and of course it's exactly the kind of variable that
should be dynamically handled.

> You need to understand that one of the strong points in favor of a dynamic 
> configuration system is to allow the user to modify things (object 
> properties) on the fly.

   Definitely.

> One solution could be to use categories to classify the config options so 
> only the important ones gets displayed in the first level of the menu and 
> if the user wants more power, he could open a second level which would show 
> all the config variables of the current object.
> 
> The other problem is where to put this menu in the GUI.

   I have no real opinion on this, and I suggest leaving this to UI
designers, or talk about it later with our interface coders' hats :)

> We could also have auto-reset variables so we could for example implement in 
> this contextual menu a next or back entry. Auto reset variables could be 
> implemented as completely new types but I would rather be in favor of using 
> the current types and just letting the programmer of the module implement a 
> config callback that would reset the value of the variable (because an 
> integer auto-reset variable can also be useful - like "forward 30seconds").

   We could also provide something in the API to set a "memory" flag to
the variable.

> > > Why not always specify the name of the module where this variable is 
> > > defined, except when this module is the main module (so general options 
> > > would have more simple names)?
> > 
> >    There are times where I'd like to set "tooltips" to 0, and have
> > tooltips disabled for the Gtk _and_ Gnome interfaces.
> 
> Yeah but you are asking for troubles here as you can't know if these two 
> variables with the same name do the same thing. You could have another 
> module with a tooltips variable which does something completely different 
> with it.

   Aaargh, you're so right. I didn't think about this. Forget about my
argument then.

> [...]

> What I'm worried about is not that you want to rewrite the code to introduce 
> the creation of config variables at run-time. What I'm worried about is the 
> consequences of this.
> The fact that a config var can be created at any time introduces 
> synchronisation issues. I'm not saying that the old (static) way doesn't 
> have any but it surely is less prone to such issues.
> As long as we create these variables during a special module initialisation 
> step then it should still be ok, but then it does strangly resemble the 
> current static creation method.

   Ok, then we could keep the configuration stuff exactly as it is,
with the config_lock mechanism that keeps synchronisation issues away,
and use the per-object variable API as a backend (variables would be
stored in the p_module object -- exactly the way it is currently done
except it'll use an API common to other things we won't consider as
configuration variables).

> There's another issue I'm worried about.
> 
> When you use run-time variables, that basically mean that a specific 
> variable may or may not be created, and we can even think about the case 
> where completely new variables will be created and will disappear each time 
> vlc is started ( snprintf(NewVariableName, "myvariable%i", rand()) ;).
> In this case how do you handle static (run-time) variables which we would 
> want to save to a config file.

   I haven't thought a lot about that, though I was aware of the
possible problems. I think we can keep it simple: if the variable
is stored in a module object, save it as if it was a static config
variable; otherwise, treat is as a run-time variable.

> In the case of your xmms wrapper plugin, I suppose you would still want to 
> be able to save or restore the config options of your xmms plugins, 
> wouldn't you?

   Yes. Assuming the module is called xmms, if it loads a plugin
called foo which has variable bar, it'll create a variable called
xmms::foo_bar (or whatever) which will be saved to the xmms module
section , then automatically recreated at next launch upon config
file loading (maybe issuing a warning because the variable is unused).

   This may raise the issue of unexisting variables: should we
silently load them, or warn the user about them because it might
be a typo? This could be module-dependent.

> And what do you do with config variables which haven't been registered 
> (created) by there module yet (e.g the module hasn't been run yet)? I 
> suppose you would still want to display it in a "preferences" menu, but how 
> because we don't know they exist?

   If we don't know they exist there must be a reason for it, so I don't
think we should display them at all. Maybe the solution is to have
"inactive" variables (we know they exist, but we can't set or get them)
that would be greyed out in the preferences panel, until they get
activated (because the related module has finished his hardware probe
for instance).

> >    This can be done in a transparent way; by default all variables can be
> > set to the p_libvlc or p_vlc object. When a variable is set, it is either
> > written to p_vlc, or transparently created in the local object and stored
> > in the local object. When a variable is read, it is read from the local
> > object if it exists, otherwise it is read from the parent object, and so
> > on until it is found (and we always reach p_libvlc this way).
> 
> To be honest, I'm not sure I understand this. Could you elaborate on this?
> Does this mean that when you create a variable at run-time, you can create 
> it as a static (global) variable if it is stored in p_vlc and a dynamic 
> (local) variable if it is stored in the object itself.

   Yes, this is basically what I mean.

> I can see 1 advantage of using this method. This will allow for a variable 
> to have several scopes... But it will make things a lot more complicated.

   If complexity is hidden inside vlc, and if we provide a simple but
powerful API to plugin or application developers, then it's all for the
better IMHO.

> >    We could adapt the current macros so that they call the proper
> > functions in this API. This would allow minimal code changes in the
> > modules.
> 
> To be honest I'm not really worried about changes in the modules. I more 
> worried about changing completely the internals of the configuration 
> framework and realizing afterwards that the new design has some major 
> flaws. This is why having this disscussion is really nice :)

   Hah. As if we ever had to completely rewrite complete parts of VLC
because the design was too old, or because we needed additional features
that couldn't be implemented :)

> I'm also all for reducing the amount of functions in VLC but in this precise 
> case I _don't want_ developpers of modules to use the functions that modify 
> the static version of the config variables! Modules should _never_ do that 
> by themselves! Only users should be able to modify them because these 
> variables do in fact correspond to the user defaults!

   Okay, I see what you mean. Let's keep the config_* functions for
configuration variables, and use var_* for other variables.

> I think that if there are different sets of functions to modify the static 
> and dynamic variables then it will be less tempting for developpers to use 
> them. And we could maybe also put them in a different header file that 
> would only be included by GUI modules to implement their "preferences menu" 
> (configuration_private.h maybe).

   Ok, that's similar to the configuration.h/variables.h distinction I
had in mind.

   I'll implement simple per-object variables ASAP because I need them
to get the mozilla plugin to work, but I won't touch the configuration
stuff, to leave us time to think about it.

-- 
Sam.
-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://www.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>