[vlc-devel] [PATCH 17/20] ADD for module configs: list of slave config options

[basos g]

2009/4/22 Rémi Denis-Courmont <rem at videolan.org>

> Le mercredi 22 avril 2009 13:03:30 basos g, vous avez écrit :
> > > A single slaves list per master will become a terrible mess if we ever
> > > need to ifdef parts of it.
> >
> > I don't see why this would happen ? It would be a list like the psz_list
> > member of the configuration item. Why should we need to ifdef something.
>
> I guess you did not look at the x264 plugin among others.
>
> > > In fact, I really don't like the way you put all the logic in the UI.
> > > That sort of stuff belongs in the core, hidden. I haven't been cleaning
> > > the module and configuration for two years for others to come and
> > > entangle it again 6 months later.
> >
> > I am not sure this is wrong. It's a GUI capability : "to fill a GUI list
> of
> > options that depend on the value of another configuration item, "
>
> > The use case scenario is :
> >    a user has opened the capture dialog and is presented with a list of
> > capture devices. He selects one device from the list. This device has
> some
> > device dependent capabilities (like the supported resolutions). These
> > capabilities should be presented to the user with a list of possible
> > values. Also these lists should be updated when the device selection has
> > been made.
>
> Sure, there would be use cases. XVideo adaptors properties are an obvious
> example... except... You can't have dynamic configuration items. Not
> without
> extensive change to the core. Things like the plugins cache, the command
> line
> parser, the configuration file loader expect a static list of configuration
> items. Another problem is that you cannot invent a short and long
> descriptions on the fly, especially not as they need to be localized.
>


It took me some time to understand what you mean and i think that you
missunderstood my concept :

I am not proposing a dynamic list of configuration items (that would impose
all the problems you mention, like plugin cache or descriptions issues).
Thinks will be defined like always.

I am proposing one more member variable on the configuration item structure.
It's purpose is to *correlate* two (already, statically defined)
configuration items in a master-slave relationship, with the goal for this
relationship to be used from the GUI to dynamically populate the slave
configuration item (that is of type "string list") according to the
selection of the master configuration item.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20090430/94b3159e/attachment.html>