[vlc-devel] Re: RFC: refurbishing the configuration manager
gbazin at netcourrier.com
Thu Oct 10 16:57:54 CEST 2002
On Thursday 10 October 2002 14:12, Samuel Hocevar wrote:
> Ok, then we could keep the configuration stuff exactly as it is,
> with the config_lock mechanism that keeps synchronisation issues away,
> and use the per-object variable API as a backend (variables would be
> stored in the p_module object -- exactly the way it is currently done
> except it'll use an API common to other things we won't consider as
> configuration variables).
See my comment about this at the end of this mail.
> > When you use run-time variables, that basically mean that a specific
> > variable may or may not be created, and we can even think about the case
> > where completely new variables will be created and will disappear each
> > vlc is started ( snprintf(NewVariableName, "myvariable%i", rand()) ;).
> > In this case how do you handle static (run-time) variables which we
> > want to save to a config file.
> 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
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
Remember, when a static config variable is created (at module load time), it
should be initialized to the value stored in the config file. And when a
dynamic config variable is created, it should be initialized from it's
corresponding static variable (which makes sense because it corresponds to
the user default).
> > And what do you do with config variables which haven't been registered
> > (created) by there module yet (e.g the module hasn't been run yet)? I
> > suppose you would still want to display it in a "preferences" menu, but
> > because we don't know they exist?
> 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!
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 understand there are some cases where being able to "inactivate" a config
option can be useful, like for instance the win32 port has some win9x
specific variables, so when running on NT we could gray them out. But this
could be done with the current scheme.
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).
In short, I've got nothing against run-time variables as long as they are
created during an initialization step of the module. But this would better
be obtained by extending the current scheme a little bit (instead of
presenting to the programmer some potentially harmful functions).
> > > This can be done in a transparent way; by default all variables can be
> > > set to the p_libvlc or p_vlc object. When a variable is set, it is
> > > either written to p_vlc, or transparently created in the local object
> > > and stored in the local object. When a variable is read, it is read
> > > from the local object if it exists, otherwise it is read from the
> > > parent object, and so on until it is found (and we always reach
> > > p_libvlc this way).
> > I can see 1 advantage of using this method. This will allow for a
> > variable to have several scopes... But it will make things a lot more
> > complicated.
> If complexity is hidden inside vlc, and if we provide a simple but
> powerful API to plugin or application developers, then it's all for the
> better IMHO.
Yeah you're right, the more I think about it now and the more I see some
interest in having scopes like this :)
But still, I think that this solution introduces quite some complexity. Not
in its implementation in itself but in the ways the user can interact with
these config variables.
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 :)
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.
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