Framework for Playlists

[Bart Cerneels]

2007/8/16, Maximilian Kossick <mkossick at gmx.de>:
>
> 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.


Seems like a good idea that won't harm anyone :) .

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.


I've already decided to start a new  framework just for Playlists.
Collections that also offer Playlists should subclass or create a member of
type PodcastProvider, DynamicPlaylistProvider, SmartPlaylistProvider,
StreamProvider, etc (note: have not created any one of those). The default
categories of Playlists are defined in the PlaylistManager::PlaylistCategory
enum. Other custom types can be created by subclassing PlaylistProvider and
registering it with a new key (int) for a custom category.
PlaylistManager allows other parts of Amarok (like PlaylistBrowser) to
request all Playlists of one of the categories that are offered by all
registered PlaylistProviders.

More to follow soon.

Stecchino
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/amarok-devel/attachments/20070816/e8cf8761/attachment.html