[vlc-devel] Re: On configuration callback paradigm

[Gildas Bazin]

On Saturday 26 July 2003 18:01, rocky at panix.com wrote:
> In adding a dynamically changable configuration variable for a
> revised VCD input plugin, I came across the following awkwardness.
> 
> I scanned the vlc source for a use of a callback on
> add_{integer,string} and couldn't find a single place where this was
> anything other than NULL. (This made me wonder...)
> 
...
> 
> The wierdness is having the callback routine retrieve the new value
> that was just set and store that into the right associated structure
> in the input thread. At first I naively thought that I could get this
> via the vlc_object_t pointer would be passed in the callback. Alas,
> vlc object is the "interface" rather than the VCD
> "input".

Ok, it's true that the callback mechanism should/could be modified to pass 
the new value.

But let's do a bit of briefing on how the configuration variables work in 
VLC.

First there's not really only one type of configuration variables. There are 
actually 2, the ones I call "configuration variables" and the others 
"object variables".

- Configuration variables: these variables basically reflect the state of 
VLC's configuration file. These are used to store global settings (session 
wide settings). If you use a "vcd-debug" config variable for instance, 
every time a vcd input is started, it will use the value in there. If you 
modify this value during run time (through the preferences panel or with 
config_PutFoo() in your vcd input) then you modify the global state and the 
next vcd inputs that will be started will use this new value. This is not 
always the expected behaviour.

- Object variables (api defined in include/variables.h and implementation in 
src/misc/variables.c): these variables are local to a vlc object (I suppose 
you noticed that vlc is using a kind of object architecture). If you modify 
them, they will only affect their owning object (for instance in your case, 
the current vcd input).
These variables are much more powerful and are now the prefered way to 
retreive a variable value (config or object). They implement callbacks the 
way you want it, they are efficient speed wise, they implement inheritance 
which allows you to retreive the value of the same variable (well, same 
variable name) in a parent object or if none exist, from the corresponding 
config variable. There are also some other nifty things.
Object variables are now also used extensively in the interfaces menus 
because they allow to have generic code (knowing only how to deal with 
object variables) to generate menus. For instance the "title" and "chapter" 
variables are used to generate menus in the wxWindows and MacOSX 
interfaces. (BTW you should really try the wxWindows interface for VLC 
which implements all these things. The GTK interface is not maintained 
anymore... well nobody seems to care about it anyway).

So rule of thumb is:
Configuration variables should only be used to store global settings 
(session wide settings) and should only be modified by the preferences 
panel of the interfaces. When you modify a setting in the preferences 
panel, currently running objects are also not required to update their 
status.
Object variables should be used if you want the user to modify a variable at 
run time like fullscreen switching etc...

Usually you will still want to create a configuration variable but you will 
not access it directly (with config_Get/Put), instead you will use object 
variables with inheritance to get a default value for your variable.

Also note that with the current cvs version of VLC, you can use MRLs (Media 
Resource Locators) that include options that will be used for the specific 
input described in the MRL.

For instance ./vlc --no-video file1.mpg file2.mpeg :video
The first MRL is "file1.mpg" and will be played without video.
The second MRL is "file2.mpeg :video" and will be played with video. The 
video option here overrides the global setting (--no-video).

You can also pass MRLs in the wxWindows interface so you can use this 
facility as well.

> 
> - - - -
> 
> The VCD plugin is now at about a minimal stage where I think others
> might try it. However with the pending vlc 0.6.1 release, my thought 
> is to wait for that release and make a patch on top of that.
> 

Great, I'm looking forward to trying it.

--
Gildas

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>