<div class="gmail_quote">On Thu, Nov 5, 2009 at 1:26 PM, Jean-Baptiste Kempf <span dir="ltr"><<a href="mailto:jb@videolan.org">jb@videolan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello,<br>
<br>
On Wed, Nov 04, 2009 at 10:13:33PM +0100, Jakob Leben wrote :<br>
<div class="im">> 1.The media browser should abstract from services discover, meaning<br>
> - we don't need a common SD top node with particular SDs as children<br>
</div>Well, maybe we do.<br>
Especially if we afterwards have a "Saved Playlists" or "Smart Playlist<br>
node".<br>
That enables to differenciate with external services (aka SD)<br></blockquote><div><br>Sorry, I still don't see the reason for that. It seems perfectly OK to me to see categories like:<br>- Now playing<br>- Saved playlists (or whatever)<br>
- Discs<br>- Internet Sources:<br>--- Podcasts<br>--- Shoutcas listings<br>--- (??SAP announcements??)<br>- External Devices         // MTP, UPnP, Bonjour<br>- (...)<br><br>... no need for setting all SDs aside at the top level.<br>
<br><br></div><div><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">All shoutcast code should die and be moved to lua, as it is SDs around<br>

some webservices that are likely to change in the future.<br></blockquote><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">

> - SDs should be distributed logically into categories that don't necessarily<br>
> map to individual SDs.<br>
</div>How are you going to do that with lua scripted SD?<br>
</blockquote><br>???<br>If you want to have lua scripted shoutcasts, fine, the simplest thing I can imagine now: add an input item with the shoutcast URL into Qt selector, make it perform and the lua script will be called. Of course, this presupposes that Qt interface does the job of organising media locations. Still, despite moving shoutcast discovery to lua, the initial shoutcast url has to be hardcoded (well, or configurable in preferences if that makes sense).<br>
<br>Later on, I also don't see a problem integrating lua script execution within the Media Provider framework (if such a thing will be developed).<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
> 2.There is specific SDs which have configurable "entry points" (for example<br>
> Podcast SD - the entry points are user configurable podcast feeds).<br>
> - In this case there should be a media browser category which has right next<br>
> to its name a "+" button which spawns a dialog for user to configure and add<br>
> a new "entry point"<br>
> - the configurable entry points spawn as the children of that category. They<br>
> have right next to them a "-" button which removes the entry point.<br>
</div>Well, I guess that podcast is different from anything else, maybe if<br>
should be treated in a different way, maybe like "smart playlists".<br></blockquote><div><br>Erm, Podcasts under category of Smart Playlists - sounds like Amarok. I never got that though, it's not how I see Podcasts.<br>
</div><div><br>You're right on the point that Podcasts are special in that add/remove configuration style. Even more so if media dirs are to become obsolete.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
> Problems and questions, remarks:<br>
> 1. In my opinion Media dirs should be configurable as well. If there is no<br>
</div>This is a preferences thing, not a selector issue. You are not going to<br>
change the folder every days. Moreover, with the SQL library, I don't<br>
really see the point of thsose.<br></blockquote><div><br>I agree. SQL library makes them unnecessary.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">So I propose to abstract from those modules and put<br>
> all the items they spawn together under one category ("Devices" or similar).<br>
> Does that make sense?<br>
</div>Why not.<br></blockquote><div><br>Allright. <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
One important thing that is missing here is a way to deactivate some SD<br>
categories.<br></blockquote><div><br>Hmm, I actually found pretty ql the change that you yourself introduced: all SDs constantly in the selector. I don't see a point to not have access to all (if the plugins are compiled and installed). Just as with other plugins, SD modules should automatically be loaded/unloaded when appropriate (by GUIs, I guess, or by the hypothetical intermediate Media Provider interface.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Finally, be careful, this isn't a Qt problem, but it should impact in<br>
the same way the OS X intf, so think wide...<font color="#888888"><br></font></blockquote><div><br>I pointed out earlier that currently my concern is simply to organise the Qt selector more logically, without  any deeper changes so I am simply seeking your opinions about what would be a logical organisation.<br>
<br>Of course everything will obtain a wider scope if / when this issues are going to be handled by something like the proposed Media Provider interface.<br><br>Kind regards<br></div></div>