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

[Gildas Bazin]

On Wednesday 09 October 2002 18:35, Samuel Hocevar 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.

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.
So a framework to handle dynamic configuration variables should also handle 
the automatic creation of a user interface (e.g a menu) to allow the user 
to modify these values. This isn't that easy as we still need to stay 
user-friendly enough and not present to the user a menu with tons of 
options when for example he right clicks on a video.

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.
It must be easy to access because these options concern dynamic properties 
of the current object. If we take the example of the fullscreen option, you 
really want the user to do minimal manipulations to access the option.

My idea on the subject would be to put this in a contextual menu like a 
right click menu. And because when we play a video we not only need to 
access the properties of the video_output object, but also the properties 
of all the objects bound to the same input stream, we could display in this 
menu all the options of the objects included in the tree starting from the 
input object.

Of course a video is not always available so we could at the same time add 
an entry in the main menu of the GUI which would open the same contextual 
menu.

Well, I hope this explanation is as clear to you as it is to me ;)

Just another thought:
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").

> 
> >      Another nice thing to have would be a scripting language that would
> >      allow to modify these local variables.
> 
>    Yes, this would definitely be cool. There's a proof of concept in the
> rc plugin that also shows the callback mechanism, try this:
> 
>     # vlc -I rc
>     intf gnome
>     set gnome-toolbartext 1
>     set gnome-toolbartext 0
> 

Hey, that's cool dude :)

>   One thing to keep in mind if we are going to use a language is not
> to try to complicate it. No loops, no tests, no complicated structures
> (I'd even say no variables). Just a few functions like "set variable",
> "new interface", "new target".
> 
>   If we want high-level stuff, we'll create Perl (or Python or Scheme
> or PHP or whatever) bindings for libvlc, and feed the script to the
> language interpreter that will spawn vlc.
> 

I completely agree.

> > 
> > 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.

The only way to be sure of what you are doing when you modify a variable is 
to know exactly which one you modify.

> > >  - we should be able to create new variables for any object that suits
> > >    us, and not restrain to the module discovery step
> > 
> > Hmmm, I'm not really sure this is actually useful.
> 
>    I'll try to elaborate on reasons that led me to this idea:
> 
>   - the existence of a variable can be a good test on whether an object
>     supports a specific feature or not without having to create a new
>     function in the API, and the feature can be runtime-dependent.

Well I would personally prefer a variable which says if the feature is 
supported or not instead of testing for the existance of a variable. IMHO 
it is better to do things explicitly.

>   - it would allow to completely unload a plugin and reload it.

I don't see the point here, we can already do that. We only keep structures 
in memory when we hide plugins to save memory utilization. But if we want 
to completely unload a plugin, we could remove everything.

> 
>    Ok, maybe the mixer example isn't very good, because mixers are tied
> hard enough to vlc to have a proper API. I thought about another one:
> imagine a module that can create modules at runtime (for instance an
> XMMS plugin loader); it will have to create variables on the fly when
> interpreting the plugin capabilites.
> 

Ok, this is a valid example (even though I still wonder if this is worth the 
complexity).

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.

There's another issue I'm worried about.

Let's first agree about the terms I will use to describe the different 
configuration variables. I will call a "static config variable" a variable 
which state is stored in the config file and which will be used to 
initialize the value of a "dynamic config variable". A "dynamic config 
variable" is a variable which is bound to an object and is only valid 
during the lifespan of this object. "dynamic config variables" are used to 
change on the fly the state of an object. A "run-time variable" is a 
variable (static or dynamic) which is created during runtime. When I don't 
specy "run-time variable" that will mean I'm talking about a "normal" 
variable.

Ok, now this point has been straighten out, let's talk about this other 
issue.
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.

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?

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?

Basically, not knowing the possible config variables at compile-time does 
make the handling of a config file a lot more difficult.

> > It is as useful to have a static version of the config
> > variable as a dynamic version (remember, one is used for the default 
> > configuration of an object and the other is used for the dynamic 
> > configuration of this object).
> 
>    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.
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.

> 
>    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 :)

> > 
> > These would be the functions to modify the local config variables.
> > We would also need to handle the global variables but instead of 
extending 
> > the above functions I would rather add a new set of functions.
> 
>    Or just add a flag to the prototypes? I'm all for reducing the
> amount of functions in VLC by the way, especially those which do
> "almost" the same thing. We could even have a vlc_var_t typedef which
> is an union of s64, mtime_t, void *, char *, float and whatever, so
> that we'd only have one var_Set() and one var_Get functions. And it
> would even fit in a register (or at least in a return value).
> 

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!
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).

By the way, I like the idea of a vlc_var_t type :)

--
Gildas
-- 
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>