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

[Gildas Bazin]

On Tuesday 08 October 2002 15:08, Samuel Hocevar wrote:
> 
>   Things I could think of:
> 
>  - variables should be stored in the object using them, or one of its
>    parents; for instance "fast-mutex" should be in p_libvlc, but "loop"
>    could have different values for each p_vlc, and "width" or "height"
>    have a meaning in all video output objects

I agree, variables should be object based, but...

There should exist two kinds of config variables:

- Global configuration variables:

    These variables allow the user to configure the default behaviour of
    vlc. When I say default behaviour I mean the default settings that vlc
    will use when it will create new objects like for instance when it
    spawns a new input or a new video output.

    This is the only type of configuration variables which is currently
    implemented.

- Local configuration variables:

     These variables allow to modify the behaviour of an object. Which means
     that the object is spawned with its configuration variables set to the
     values of the global configuration but their values can be modified
     afterwards.

     I don't think this kind of variables is really necessary because you
     can create them programmatically in your module. For instance the
     video output modules use a b_fullscreen boolean to set the currently
     requested fullscreen mode.
     However, this is a really nice feature as it will standardize the
     access to these configuration variables and for instance allow external
     modules (like the mozilla plugin) to modify these variables through a
     nice API.

     I never had time to do this part, mainly because what I wanted to do
     was quite complex. For instance one nice feature of these variables is
     to allow modules to define variables that are dynamically modifiable by
     users, but _how_ do you give a user the possibility to modify them ?
     Certainly not through the "preferences menu" because this one is by
     definition used to modigy the global variables in order for the user
     to save its default configuration.
     So you need a new menu per "living" object to allow the user to
     dynamically modify the configuration of this object. Hmmm, not easy to
     integrate in a GUI...

     Another nice thing to have would be a scripting language that would
     allow to modify these local variables. You would then be able to
     control VLC with little scripts saying things like "run mympegfile1.mpg
     in fullscreen with such video filter, and once your are finished, run 
     this other file with those parameters....". Of course the details of
     this scripting language still have to be defined (format, grammar,
     etc...)

>  - if module foo and module bar define the variable "quux", we can
>    differenciate them by using "foo::quux" or "bar::quux"; exact
>    behaviour when setting or getting the value is yet to be decided
>  - if object 12 and object 42 use the variable "wok" we can
>    differenciate them by using "12::wok" and "42::wok" or maybe
>    something else to be decided

I didn't define namespaces like these mainly because it renders the command 
line interface more complex, but now I tend to think that it was a bad 
choice...

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)? This also has the advantage of reducing the 
cost of the variables lookup.

>  - 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. And this would for sure 
make things more complicated (and I'm not even talking about the fact that 
if you do this then it is quite difficult to know if and when a variable 
has been created). Unless I'm missing something, this feature is IMHO 
overkill.

I also don't think that we need to differentiate between the creation of a 
global or local config variable, because afaics a config variable always 
need to be created as both. 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).

What I have in mind would rather be to keep the current way of declaring 
config variables ( to create the global (static) version of the config 
variables). Then when a new object is spawned, we would create a local 
version of these config variables (just by duplication module_config_t), 
that way the new object starts with the user's defaults. 

>  - we should be able to dynamically add items to list variables; for
>    instance the discovery of a new audio device adds a string to the
>    "audio-device" variable; removal should be possible as well
>  - range variables such as "volume" should be checked for validity
> 

Yeah, all this would be nice indeed :)

>   Here are a few function prototypes to give you an idea of what I
> intend to do:
> 
>     /* New stuff */
>     void var_New( vlc_object_t *, char *psz_name, int i_type );
>     void var_SetScope( vlc_object_t *, char *psz_name, int i_scope );
>     void var_Delete( vlc_object_t *, char *psz_name );
> 
>     /* i_type could be one of STRING, BOOLEAN, INT, INT_FROM_LIST, FLOAT,
>      * FLOAT_FROM_LIST, STRING_FROM_LIST, but also derivate types such as 
FILE,
>      * FONT, TIMESTAMP... */
> 
>     /* i_scope could be one of OBJECT_LOCAL, VLC_LOCAL, GLOBAL... */
> 

As explained above, I would rather keep the current macros (add_string, add 
string_from_list, etc...).

> 
>     /* Functions that we already have (could be merged into one function
>      * and several macros) */
>     int var_SetInt( vlc_object_t *, char *psz_name, s64 i_value );
>     int var_SetString( vlc_object_t *, char *psz_name, char *psz_value );
>     int var_SetFloat( vlc_object_t *, char *psz_name, float f_value );
> 
>     s64 var_GetInt( vlc_object_t *, char *psz_name );
>     char * var_GetString( vlc_object_t *, char *psz_name );
>     float var_GetFloat( vlc_object_t *, char *psz_name );
> 

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, because 
these functions should exclusively be used by the "preferences menus". 
(modules should only need to access the local versions of the variables).

int globalVar_SetInt(  char *psz_module, char *psz_name, s64 i_value );
int globalVar_SetString( char *psz_module, char *psz_name, char *psz_value);
int globalVar_SetFloat( char *psz_module, char *psz_name, float f_value);

The "char *psz_module" parameter is needed to define a namespace for the 
config variable (the namespace is the module name).

>     void var_SetRange( vlc_object_t *, char *psz_name, s64 i_min, s64 
i_max );
>     void var_AddChoice( vlc_object_t *, char *psz_name, char *psz_choice);

the same for these:
void globalVar_SetRange( char *psz_module, char *psz_name, s64 i_min, s64 
i_max );
void globalVar_AddChoice( char *psz_module, char *psz_name, char 
*psz_choice);

Well, I think that's all the comments I have so far ;)

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