<br><br><div class="gmail_quote">2009/4/22 Rémi Denis-Courmont <span dir="ltr"><<a href="mailto:rem@videolan.org">rem@videolan.org</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Le mercredi 22 avril 2009 13:03:30 basos g, vous avez écrit :<br>
<div class="im">> > A single slaves list per master will become a terrible mess if we ever<br>
> > need to ifdef parts of it.<br>
><br>
> I don't see why this would happen ? It would be a list like the psz_list<br>
> member of the configuration item. Why should we need to ifdef something.<br>
<br>
</div>I guess you did not look at the x264 plugin among others.<br>
<div class="im"><br>
> > In fact, I really don't like the way you put all the logic in the UI.<br>
> > That sort of stuff belongs in the core, hidden. I haven't been cleaning<br>
> > the module and configuration for two years for others to come and<br>
> > entangle it again 6 months later.<br>
><br>
> I am not sure this is wrong. It's a GUI capability : "to fill a GUI list of<br>
> options that depend on the value of another configuration item, "<br>
<br>
> The use case scenario is :<br>
>    a user has opened the capture dialog and is presented with a list of<br>
> capture devices. He selects one device from the list. This device has some<br>
> device dependent capabilities (like the supported resolutions). These<br>
> capabilities should be presented to the user with a list of possible<br>
> values. Also these lists should be updated when the device selection has<br>
> been made.<br>
<br>
</div>Sure, there would be use cases. XVideo adaptors properties are an obvious<br>
example... except... You can't have dynamic configuration items. Not without<br>
extensive change to the core. Things like the plugins cache, the command line<br>
parser, the configuration file loader expect a static list of configuration<br>
items. Another problem is that you cannot invent a short and long<br>
descriptions on the fly, especially not as they need to be localized.<br>
</blockquote></div><br><br>It took me some time to understand what you mean and i think that you missunderstood my concept :<br><br>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.<br>
<br>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.<br>
<br><br>