<br><br><div class="gmail_quote">2009/4/21 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 mardi 21 avril 2009, basos g a écrit :<br>
<div class="im">> I understand that this would be more convenient when declaring<br>
> masters. And i could provide a modified implementation for the plugin<br>
> interface (e.g. provide a master with the apropriate call to a macro<br>
> at the declaration of the slave plugin, rather a list of slaves at<br>
> the declaration of a master plugin). But the underlying structure<br>
> would still be a list of slaves stored at the master configuration.<br>
> This is needed as it will provide faster execution ( bear in mind<br>
> that slaves seeking could be triggered by UI events and should<br>
> respond fast enough). Also the implementation for this is already<br>
> defined.<br>
<br>
</div>A single slaves list per master will become a terrible mess if we ever<br>
need to ifdef parts of it.</blockquote><div> </div><div>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.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<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>
<div><div></div><div class="h5"></div></div></blockquote><div><br>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, "<br>
<br>The use case scenario is :<br>   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.<br>
<br>In my implementation the logic for the above scenario is implemented in the GUI. But to be accomplished it needs support from a configuration item capability: the psz_slaves_list, that is optional and with no side effects to the core as it's an informative only list.<br>
<br>So i believe that the logic is correctly split.<br><br> If you have another proposal for the logic tell it.<br></div></div>