Framework for Playlists

[Maximilian Kossick]

On Thursday 16 August 2007, Bart Cerneels wrote:
> Hi all
>
> I've been pondering how to properly manage Meta::Playlists within
> Amarok and I'm conflicted.
>
> Most Playlists will contain Meta::Tracks that come from a Collection,
> and those Playlists should be provided by the Collection.
> When mediadevices are implemented as Collections (that is the plan
> right), they will deliver the Playlists populated with tracks in it's
> own Collection.
> Dynamic and smart Playlists will not be created by a Collection but
> will use Tracks from the available Collections.
> These points suggest that adding Playlists to the Collection Framework
> is a good idea. It seems to me there are technical hurdles though.
> Everything in a collection is tight together using Tracks, there is no
> way of going straight from Artist to Albums for instance, you have to
> use a Track. So unless we add a Meta::PlaylistList to every Track
> there is no easy way of querying for Playlists. There are other
> problems to, like PodcastEpisodes and Streams showing up in the
> CollectionBrowser unless they are specifically excluded.

Adding an albums() method to Meta::Artist is a good idea, especially because 
Meta::Album already has an albumArtist() method. Albums and Artists are a 
special case, I don't think it makes sense to add similar methods to Genre, 
Year and Composer because I can't see a real need for them...just use 
QueryMaker instead.

I don't think that the collection architecture is the right tool for podcasts 
and a stream directory like shoutcast (DAAP and stores like magnatune are 
different) You can write another framework which fits your need better than 
the current collection framework. You only have to be able to provide 
Meta::Track objects, because the engine can only play those.


> Another way might be a PlaylistManager where portable devices,
> internal functions, scripts, etc register Playlists they create. These
> Playlists don't have to be tight to a Collection at all (but they have
> to be able to use them) and so those Tracks won't pollute the
> CollectionBrowser. I guess creating a PlaylistProvider abstract base
> class is the way to do this, looks an awful lot like Collection
> though.

Well, as mentioned above, playlists (and podcasts) don't belong in the 
collection browser. It is only useful to put them there to get the 
development started more easily.

I can't really comment on the PlaylistManager, because I don't really 
understand what you want to do with it. I'm sorry that I can't be IRC a lot 
at the moment, but maybe you can explain it in more detail in another e-mail.

> I'm undecided about the best solution but I believe the #2 will be the
> easiest to implement.
>
> I'm sure you guys have ideas about this, let me hear them.
>
> Stecchino

Max
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20070816/5a3c59bc/attachment.pgp