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

Gildas Bazin gbazin at netcourrier.com
Sat Oct 12 11:50:29 CEST 2002


On Saturday 12 October 2002 00:12, Samuel Hocevar wrote:
> 
>    Anyway, this part of the discussion is going nowhere. The only point
> I'm trying to make is that there are variables that are currently shared
> between different parts of VLC using a structure, while they could be
> stored using simple named variables.
> 
>    (I also have a subliminal message here: ABI stability, libvlc).
> 

No need to remind me that. This was understood right from the beginning.
The point we were arguing about is wether it could also be interesting to 
let the user save the default values of these variables.

But I personnaly consider this point settled if we can agree on the 
necessity of the creation of initialization-time variables _and_ run-time 
variables.

> > 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...
> 
>    Hah. This already happens if you install a new plugin. Or if a plugin
> becomes unavailable for whatever reason. Or if you use the --plugin-path
> option with different values.
> 

The BIG difference here is that the user is in _control_ when he installs 
(uninstalls) a new plugin or use the --plugin-path so he expects that the 
preferences panel will change as well as the configuration options he's 
able to save.

But what you are proposing is to take this control from the user and to 
randomly change (at run-time) what he is able to save as config options.
Honestly this isn't what I call a user friendly behaviour.

> 
>    Ok, I won't touch the config_* API. But you will die of utter jealousy
> when you see my cool new features, muahahaha :-)
> 

I _know_ your ideas add some really cool new features. All I want to be sure 
is that they will be used properly. And being able to create variables at 
run-time can IMHO be dangerous if wrongly used. This is why (again IMHO) 
having two different APIs to create initialization time variables and 
run-time variables will make things clearer to the programmer.

> > 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).
> 
>    I'm sure I can find some examples where we'll need ugly workarounds,
> for instance how do we save per-device configuration when a module can
> support several devices (per-soundcard volume, per-display Shm usage...)?
> 

Unless the module does this kind of probing at initialization time, then 
there's no way you can save the config vars.
As I said, it's not a technical problem, but a user-friendlyness problem. 
You cannot present the user with a preferences panel which will change (add 
new entries, remove existing entries, etc...) itself _randomly_ at 
run-time. If you do so, the user will never be able to save its preferences 
as and when he wants to.

I think that when you will understand that, we'll be able to come to an 
agreement ;)

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



More information about the vlc-devel mailing list