Architecture discussion: the Collection Meta Framework Use/Misuse

[Bart Cerneels]

On Wed, Mar 12, 2008 at 5:29 PM, Maximilian Kossick
<maximilian.kossick at googlemail.com> wrote:
>
> On Wed, Mar 12, 2008 at 3:19 PM, Bart Cerneels <bart.cerneels at kde.org> wrote:
>  > On Wed, Mar 12, 2008 at 1:48 PM, Maximilian Kossick
>  >
>  > <maximilian.kossick at googlemail.com> wrote:
>  >  >
>  >
>  >
>  > > On Mon, Mar 3, 2008 at 5:20 PM, Bart Cerneels <bart.cerneels at kde.org> wrote:
>  >  >  > In a different thread with cryptic title
>  >  >  >  extragear/multimedia/amarok/src/servicebrowser/lastfm, Maximilian
>  >  >  >  asked for a class diagram of the current Meta::Playlist classes. Here
>  >  >  >  they are:
>  >  >  >  http://users.telenet.be/shanachie/files/amarok/Meta_Playlist.pdf
>  >  >  >
>  >  >  >  These are only the Meta Classes, the rest is best explained functionally:
>  >  >  >
>  >  >  >  PlaylistProvider is equivalent to TrackProvider, it just implements a
>  >  >  >  few functions to register an amarok subsystem to PlaylistManager as
>  >  >  >  something that delivers Meta::Playlists of a certain Category.
>  >  >  >  PlaylistManager::PlaylistCategory is an enum for the build-in types
>  >  >  >  but a function allows plugins or scripts to register a dynamic
>  >  >  >  PlaylistCategory for playlsit types that don't fit any of the standard
>  >  >  >  categories.
>  >  >  >  PlaylistManager can be queried for Playlists of a certain type,
>  >  >  >  grouping all Meta::Playlists from all subsystems of Amarok.
>  >  >  >  An example:
>  >  >  >     The category PodcastChannel is delivered by the Local
>  >  >  >  PodcastCollection but also by an iPod MediaDevice.
>  >  >  >     So we can add Podcasts to Local or to iPod transparently.
>  >  >  >     Using a system similar to CollectionLocation the Local and iPod
>  >  >  >  Podcasts can be kept synced or we can copy PodcastChannel
>  >  >  >  subscriptions from local to the iPod.
>  >  >  >
>  >  >  >  You'll notice familiar concepts similar to trackProvider -
>  >  >  >  CollectionManager - Meta::Observer CollectionLocation return in the
>  >  >  >  Playlists.
>  >  >  >
>  >  >  >  Hope this helps to understand the Meta::Playlist system.
>  >  >  >
>  >  >  I just saw meta/DynamicPlaylist.h, and remembered that I forgot to
>  >  >  send this e-mail...sorry for that
>  >  >
>  >  >  I've got a few comments and questions regarding that class diagram:
>  >  >  It looks like you generated it from the existing sources. It does not
>  >  >  contain a class for smart playlists. Do you want to integrate smart
>  >  >  playlists (and dynamic playlists, although they are a special case
>  >  >  because they require a new TrackAdvancer) into the playlists
>  >  >  framework?
>  >  I would yes, they should be saveable and behave just like the other playlists.
>
>  Ok, but see the comment in my original e-mail. Dynamic Playlists wrap
>  a smart playlist (well, actually any other playlist),
>  and support accessing those playlists track by track. It simply does
>  not make sense for dynamic playlists to have a tracks() method.
DynamicPlaylist is a proxy then, seems logical to do that. And that
way we'll have many different dynamic modes:
- SimilarDynamicPlaylist for similar artists
- MoodDynamicPlaylist based on audio analysis
- ScriptedDynamicPlaylist
and these can be added with plugins.
And yes, dynamic will need it's own TrackAdvancer but at least we'll
have only one TrackAdvancer for all DynamicPlaylist. Besides, isn't a
random playlist just a form of dynamic? On the doesn't add any Tracks.

>
>
>  >
>  >  >
>  >  >  Why is there a load(QTextStream) method in Meta::Playlist. Doesn't it
>  >  >  make more sense to put that into the implementation ctor?
>  >  Yes probably, this is the result of copy pasting from other code.
>  >
>  >
>  >  >  If we want to integrate smart playlists, Playlist::tracks() should be
>  >  >  made asynchronous.
>  >  >  I don't think we need prettyName. It does some magic if a file's tag
>  >  >  are incomplete, but I don't think that's a problem with playlists.
>  >  XSPF has title in it's metadata, so would a SQL implementation, yet
>  >  the standard name() might be the xspf filename or "SQL: ".
>  >
>  I didn't think of that. We need some kind of id for composite dynamic playlists.
>  How about renaming name() to id() and prettyName() to name() ?
>
> >
>  >  >  What's the use case for retrievableUrl?
>  >  Drag and drop to outside of Amarok, i.e. copy to a folder by dragging
>  >  from the playlistbrowser. The retrievalbleurl would be a reference to
>  >  the Playlist. I'm not sure this will work since I don't know D'n'D
>  >  very much.
>
>  How about calling it url() instead. unless we have an url() method as
>  in Meta::Track (which shouldn't actually be called url(), but it's a
>  bit late to change that now), there's no need to call it
>  retrievableUrl().
That can work.

>
>
>  >
>  >  >  And I'm not sure what advantage capability interfaces give us in this
>  >  >  case? We could add a Playlist::type method, which would allow us to
>  >  >  sort the playlists in the playlist browser
>  >  >  Or is grouping playlists in the playlist browser not what you want
>  >  >  Capabilities for?
>  >  No, for the same reason as in the CollectionTreeView, I want to keep
>  >  out implemetation details from specific Playlist versions (like SQL,
>  >  XSPF, webservice) from the playlistbrowser.
>
>  I still don't get it. What kind of implementation details are you
>  talking about? I don't think capabilities are necessary for stuff like
>  editing a playlist. Can you give a few examples what kind of
>  implementation details you'd make accessible using capabilities?

I'm talking about stuff like synching a WebServicePlaylist with a the
web, specific stuff for the type of PodcastChannel implementation
(like say IPodPodcastChannel), etc. All the stuff we might no think
about now and don't want to create a custom GUI for. We want them in
the regular playlistbrowser (PlaylistBrowserNS::) Categories.
>
>
>
>  >
>  >  >
>  >  >  Plaese note that it does not make sense for DynamicPlaylist to inherit
>  >  >  from Playlist. Dynamic Playlist has to wrap a querymaker, and needs a
>  >  >  method to access the next track to insert into the playlist, not to
>  >  >  access all tracks.
>  >  >
>  >  >
>  >
>  >
>  > > _______________________________________________
>  >  >  Amarok-devel mailing list
>  >  >  Amarok-devel at kde.org
>  >  >  https://mail.kde.org/mailman/listinfo/amarok-devel
>  >  >
>  >
>