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

[Samuel Hocevar]

On Thu, Oct 10, 2002, Gildas Bazin wrote:

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

   Well we don't agree because I think there are variables that need not
be saved at all. If an interface plugin exports a variable containing
the address of a drawable widget so that the video output can hook to
it, this is hardly something we'll ever want to save. 

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

   Yes, yes, yes. I'll probably agree with anything you'll say about
_configuration_ variables, you know :-)

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

   No because my hardware probe example may not necessarily take place
during module initialization (it can be a costly operation requested by
the user).

   And if the preferences panel is dynamically built, it's also for a
reason. We could refresh it on some occasions (a module gets added or
reloaded -- but this is only one example).

> 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'm definitely not suggesting all of them would have to be created
in the initialization. I'm suggesting that we should not restrain to
this because we might find it useful from time to time.

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

   I'm beginning to understand what's worrying you, but the xmms plugin
example still worries me, and here is another one: an equalizer filter
module; we want it to be very configurable, so we let the user define
his own frequency bands, how would we handle this apart from creating as
many variables as there are frequencies?

   Actually we'll have this problem each time the number of variables
depends on something else. Sometimes this amount has a maximal value
so it's easy to pre-create them and hide the unused ones, but in the
few examples I gave there is no real limit.

   Another concern is the reloading of a plugin. XMMS segfaults if you
reload a plugin that has been slightly changed (during an upgrade for
example) and I find this lame. Unloading a plugin, reloading it, and
seeing that it has changed its configuration variables isn't very
different from having a plugin that creates new configuration variables
during its lifetime.

> [...]
>
> 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 :)

   I'm not entirely sure it's feasible, but it's definitely enjoying
to try to implement 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.

   Yep.

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