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

[Gildas Bazin]

On Thursday 10 October 2002 14:12, Samuel Hocevar wrote:
> 
>    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).
> 

See my comment about this at the end of this mail.

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

This is where we don't agree. For me every variable should have a static and 
a dynamic instance in order to be able to save every variables to a config 
file.
Let's take again the case of the fullscreen variable. This variable will be 
as useful as a static variable (to automatically start a video in 
fullscreen mode) than a dynamic variable (to let the user dynamically 
switch to fullsrcreen).

I mean, if you give the user some kind of configuration choice, it's better 
if you also give him the choice to store a default value for this 
configuration variable.

Remember, when a static config variable is created (at module load time), it 
should be initialized to the value stored in the config file. And when a 
dynamic config variable is created, it should be initialized from it's 
corresponding static variable (which makes sense because it corresponds to 
the user default).

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

So what you mean is that a config variable cannot be created whenver you 
want! It has to be created during the initialization step of the module! 
Otherwise we will never know it could exist and thus won't be able to 
display it even greyed out!

I don't know if you realize that, but being forced to create run-time 
variables in a initialization step of the module, does resemble strangely 
to a static creation.

I understand there are some cases where being able to "inactivate" a config 
option can be useful, like for instance the win32 port has some win9x 
specific variables, so when running on NT we could gray them out. But this 
could be done with the current scheme.

I really think that we should know all the variables used (actually used or 
potentially useable) by a module after it has been initialized. If only 
because this allows the user to save a _complete_ config file, which can be 
really helpful for instance if the user uses its config file on several 
different computers (roaming profile).

In short, I've got nothing against run-time variables as long as they are 
created during an initialization step of the module. But this would better 
be obtained by extending the current scheme a little bit (instead of 
presenting to the programmer some potentially harmful functions).

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

Yeah you're right, the more I think about it now and the more I see some 
interest in having scopes like this :)

But still, I think that this solution introduces quite some complexity. Not 
in its implementation in itself but in the ways the user can interact with 
these config variables.

The interesting aspect is that for instance if you have two different 
interface objects, you could set a x11::fullscreen variable in one of the  
interface and then automagically all the x11 video output that would be 
spawned from this interface would switch to fullscreen. Whereas the video 
ouptut spawn from the other interface would stay normal size.
Sweet, isn't it :) ?

Now the problem would be to find a nice and easy way to let the user 
configure all this. This is getting really complicated, but if you think it 
is feasible than ok, I'm all for it :)

Just another note: using this scheme has the advantage of making global 
variables just a special case of dynamic variables. Global variables would 
just be dynamic variables of scope 0, that is assigned to the root object. 
And if we consider that objects cannot modify a variable from one of its 
parent objects (basically setting a variable would create a new one at the 
local scope) then we would also implicitly have the protection I was 
talking about considering random objects modifying global variables.

Regards,

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