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

[Gildas Bazin]

On Thursday 10 October 2002 19:07, Samuel Hocevar wrote:
> 
>    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. 
> 

I think you are assuming too much about what the user wants to do or not.
If my computer is always on and I have a drawable always present on my 
screen, why wouldn't I want to save this configuration option?
I know this is something that would be hardly used but nonetheless we 
already provide this configuration variable so why not let the user be able 
to save this?

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

Really nice, so the user will only be presented with the option to save some 
configuration variables at random times. That will be fun for users... a 
new game in itself... forget about vlc as a multimedia player, you can 
transform it in a brand new game where the goal would be to manage to save  
config options ;)

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

The problem here comes from run-time config variables because we do not know 
if and when they will be created, then we can't practically create them as 
static config variables (config variables that can be saved). By the way, 
it's not that we wouldn't want to, it's just that it ain't practical.

Ok, I think we can come to a compromise here by providing two different APIs 
to create the two kinds of config variables.

One would create a run-time variable and as such, this variable wouldn't be 
static but just dynamic. So there would be no way to save it.

Another one would create initialization-time variables and as such, these 
variables would be created as static _and_ dynamic. You would be able to 
save these config var (well the static version), but as implied by their 
name, they would have to be created during an initialization step of the 
module (so we can know about them right from the beginning).

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

Yes it is. In one case you trigger the operation, in the other it is 
completely random.

Run-time config variables are created at completely random times so you will 
not be able to save them whenever you want.

On the contrary, we have the possibility to reload all the unloaded plugins 
when the user clicks on the preferences menu.

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