2007/8/16, Maximilian Kossick <<a href="mailto:mkossick@gmx.de">mkossick@gmx.de</a>>:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thursday 16 August 2007, Bart Cerneels wrote:<br>> Hi all<br>><br>> I've been pondering how to properly manage Meta::Playlists within<br>> Amarok and I'm conflicted.<br>><br>> Most Playlists will contain Meta::Tracks that come from a Collection,
<br>> and those Playlists should be provided by the Collection.<br>> When mediadevices are implemented as Collections (that is the plan<br>> right), they will deliver the Playlists populated with tracks in it's
<br>> own Collection.<br>> Dynamic and smart Playlists will not be created by a Collection but<br>> will use Tracks from the available Collections.<br>> These points suggest that adding Playlists to the Collection Framework
<br>> is a good idea. It seems to me there are technical hurdles though.<br>> Everything in a collection is tight together using Tracks, there is no<br>> way of going straight from Artist to Albums for instance, you have to
<br>> use a Track. So unless we add a Meta::PlaylistList to every Track<br>> there is no easy way of querying for Playlists. There are other<br>> problems to, like PodcastEpisodes and Streams showing up in the<br>
> CollectionBrowser unless they are specifically excluded.<br><br>Adding an albums() method to Meta::Artist is a good idea, especially because<br>Meta::Album already has an albumArtist() method. Albums and Artists are a
<br>special case, I don't think it makes sense to add similar methods to Genre,<br>Year and Composer because I can't see a real need for them...just use<br>QueryMaker instead.</blockquote><div><br>Seems like a good idea that won't harm anyone :) .
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I don't think that the collection architecture is the right tool for podcasts
<br>and a stream directory like shoutcast (DAAP and stores like magnatune are<br>different) You can write another framework which fits your need better than<br>the current collection framework. You only have to be able to provide
<br>Meta::Track objects, because the engine can only play those.</blockquote><div><br>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.
<br>PlaylistManager allows other parts of Amarok (like PlaylistBrowser) to request all Playlists of one of the categories that are offered by all registered PlaylistProviders.<br><br>More to follow soon.<br><br>Stecchino<br>
</div></div>