View source for Amarok/Proposals/PlaylistRedesign

[[Category:Amarok]] [[Category:Proposals]]
For a Summer 2007 Summer of Code project, [[user:Eean|Ian Monroe]] will be working on a refactor and redesign of the playlist. I wanted to get a head start with the planning before the 'summer of code' officially gets under way (in late May).
==Summary==
At the heart of Amarok is the playlist. Currently the Playlist class performs many functions. My proposal is give the playlist the tender love it truly deserves, by first making the playlist more modular and then redesigning its layout to improve its usability. The playlist is the central feature of Amarok, it needs to look good.
[[Image:justplaylist.png|right|150px]]

==Playlist Refactor==
All classes in the Playlist:: namespace.
*Model - a class containing a list of tracks, currently playing track. It is really the meat of the playlist. The goal of all the other classes is essentially to make this class less bloaty. Its singleton and used by the rest of Amarok to add tracks, clear it, etc.
**TrackAdvancer- Maybe 'controller' isn't quite the right term. Basically it decides what to do when a track ends, so it should be an EngineObserver. An abstract class. 
***StandardTrackAdvancer - play the next track. stop at the end of the playlist.
***RandomAdvancer - the various random modes. I think all the various random modes could be in one class. By the same logic, it could be combined with StandardPlay. To start off with at least I want to keep them seperate.
***DyanmicAdvancer - removes tracks from the beginning, adds new tracks according to user rules at the end
**QUndoCommand - Qt has a Undo Framework that works nicely for the playlist, based on the Command pattern. Commands reimplement undo and redo funtions and the redo function is run when the command is created.
***AddTracksCmd - add tracks to the playlist
***RemoveTracksCmd - remove tracks from the playlist
*Delegate - draws the playlist. We could have more then one type of delegate for the playlist and swap between them, if only for experimentation.
*View - send user events to the Model.

==User Interface Improvements==
Separating the model and the view will also make improving the view easier. I'm considering implementing the playlist as in Max Howell's mockup. With such a radical UI change it will be necessary to seek user feedback and make necessary changes. From that mockup several issues present themselves - how will sorting work? Currently there are more then a dozen fields that the user can choose to have the playlist show (Artist, Composer, Bitrate etc.). Its now just a simple menu - how should it present itself with two lines? These issues will have to be solved.

==Timeline==
[[Image:Picardengage.jpg|right|thumb|300px|Captain Picard engaging the playlist redesign]]
*Design new playlist classes. 
*Implement playlist classes. PlaylistWidget might look much like the 1.4.5 playlist at this point. This will probably have to be done either using a branch because...
*Port the rest of Amarok to new playlist
*While doing all of the above, seek help regarding how to proceed on the PlaylistWidget (mainly flushing out the details of mxcl's mockup.)
*Implement PlaylistWidget
*Bug fix

==Random Todo==
*The issue where the Magnatune info gets overridden by the engine's shoutcast. Some way to lock text?
*Dynamic playlist done on the album-level instead of just the track-level.
*<icefox> http://labs.trolltech.com/page/Projects/Itemview/Modeltest
:<icefox> no model survives :)
*Read http://wiki.kde.org/tiki-index.php?page=ItemView Tips