[vlc-devel] Re: RFC: refurbishing the configuration manager
gbazin at netcourrier.com
Tue Oct 8 20:26:16 CEST 2002
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
- 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
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
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,
> - 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
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
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
> * 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
> /* 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
> 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
void globalVar_AddChoice( char *psz_module, char *psz_name, char
Well, I think that's all the comments I have so far ;)
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