generic architecture for playlists

Maximilian Kossick maximilian.kossick at googlemail.com
Sun Jun 15 15:45:16 CEST 2008


Hi,
after friday's discussion on playlists I sat down and wrote a patch
that is my vision on how we should handle playlists in A2.
Couple of points:
-Bart's playlistprovider does for playlists what collection does for
tracks. it represents a source of playlists, think ipod or
sqlplaylists (no need for a playlist querymaker though. there won't be
thousands of playlists, so just load all of them at once)
-playlists can be organised in folders. to avoid having to special
case this for each playlistprovider, all playlistproviders will return
playlistitems(which are the nodes in a tree). playlistitem should make
it pretty easy to write a treemodel for playlists, or adapt the
existing one.
-playlistitems can belong to categories, which allows playlistbrowser
to organise them properly

open issues:
-podcasts: at the moment, playlistitems leaves can be either
playlists, smartplaylist or dynamicplaylists (also the last do not
actually exist yet). i'm not yet sure how to best fit podcasts into
this design yet.

i'll have to leave soon, and I still haven't been able to set up a
development enviroment on my macbook, so here is a patch with the
current work. hopefully somebody else will be able to finish it
(mainly make amarok compile and adapt it to the new classes). it
should be pretty painless to adapt the existing sqlPlaylist stuff to
work with the new classes.

feel free to send me an email if there are any questions/comments about it.

cheers, max
-------------- next part --------------
A non-text attachment was scrubbed...
Name: playlist.diff
Type: text/x-diff
Size: 6384 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20080615/096d5bab/attachment.bin 


More information about the Amarok-devel mailing list