[vlc-devel] Qt media browser (playlist selector) reorganisation

[Jakob Leben]

On Thu, Nov 5, 2009 at 1:26 PM, Jean-Baptiste Kempf <jb at videolan.org> wrote:

> Hello,
>
> On Wed, Nov 04, 2009 at 10:13:33PM +0100, Jakob Leben wrote :
> > 1.The media browser should abstract from services discover, meaning
> > - we don't need a common SD top node with particular SDs as children
> Well, maybe we do.
> Especially if we afterwards have a "Saved Playlists" or "Smart Playlist
> node".
> That enables to differenciate with external services (aka SD)
>

Sorry, I still don't see the reason for that. It seems perfectly OK to me to
see categories like:
- Now playing
- Saved playlists (or whatever)
- Discs
- Internet Sources:
--- Podcasts
--- Shoutcas listings
--- (??SAP announcements??)
- External Devices         // MTP, UPnP, Bonjour
- (...)

... no need for setting all SDs aside at the top level.


All shoutcast code should die and be moved to lua, as it is SDs around
> some webservices that are likely to change in the future.
>

> - SDs should be distributed logically into categories that don't
> necessarily
> > map to individual SDs.
> How are you going to do that with lua scripted SD?
>

???
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).

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).


> 2.There is specific SDs which have configurable "entry points" (for
> example
> > Podcast SD - the entry points are user configurable podcast feeds).
> > - In this case there should be a media browser category which has right
> next
> > to its name a "+" button which spawns a dialog for user to configure and
> add
> > a new "entry point"
> > - the configurable entry points spawn as the children of that category.
> They
> > have right next to them a "-" button which removes the entry point.
> Well, I guess that podcast is different from anything else, maybe if
> should be treated in a different way, maybe like "smart playlists".
>

Erm, Podcasts under category of Smart Playlists - sounds like Amarok. I
never got that though, it's not how I see Podcasts.

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.


> > Problems and questions, remarks:
> > 1. In my opinion Media dirs should be configurable as well. If there is
> no
> This is a preferences thing, not a selector issue. You are not going to
> change the folder every days. Moreover, with the SQL library, I don't
> really see the point of thsose.
>

I agree. SQL library makes them unnecessary.


> So I propose to abstract from those modules and put
> > all the items they spawn together under one category ("Devices" or
> similar).
> > Does that make sense?
> Why not.
>

Allright.

One important thing that is missing here is a way to deactivate some SD
> categories.
>

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.


> Finally, be careful, this isn't a Qt problem, but it should impact in
> the same way the OS X intf, so think wide...
>

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.

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.

Kind regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20091106/c14bce3d/attachment.html>