Tag Archives: GSoC2009

GSoC final report: Amarok’s playlist, hacked into submission

When I started working on my proposal for what would eventually become my Google Summer of Code 2009 project, I was a much less skilled coder with no experience on something as large as this project turned out to be. I’m not bragging about becoming so insanely wiser now, but I have certainly gained tons of valuable experience, learned a lot about software development, and had a great time doing it!

So what exactly have I accomplished this summer?

Those who have been following my updates might remember the first part.

Well, the initial idea was to implement multilevel sorting in Amarok’s playlist, with a nice GUI, and throw in configurable grouping if there’s time. However right from the start it was clear that much more invasive changes were needed. As I already mentioned, Amarok’s playlist uses Qt’s Model/View design pattern. When I began working on my project the playlist had a source model (a class which feeds the rows), a filter proxy model (which filters out some rows that don’t need to be shown when a filter is active), a grouping proxy model (which decides which tracks should be grouped together because they belong to the same album) and finally, the view. Ideally, each model should talk only to the model right below it (if any), and the view should only talk to the “topmost” model to avoid any screw-ups in row presence and order. Failure to enforce this results in spaghetti code, which is exactly what was going on in the playlist code at the time.

So most of my first GSoC month I spent despaghettifying these Model/View classes, so that the Playlist::Model feeds data only to the FilterProxy, which feeds data only to the GroupingProxy, which feeds data only to the view. During this despaghettification, I also added a new proxy model: SortProxy, which is the class that actually implements the multilevel sorting backend. A month or so later I also added another proxy, SearchProxy, by decoupling searching from filtering. So the final result, as I already mentioned, is Playlist::Model->Filter->Sort->Search->Grouping->View: 5 models and one view. Doing all this without Qt’s Model/View classes would have been *a lot* harder and much more chaotic. So by the end of the second month the playlist code was refactored and made much clearer, the right auxiliary classes had been associated with the right model or proxy (mostly the topmost one, GroupingProxy) and a simple testing GUI was in place for multilevel sorting.

For the GUI, I chose to adapt a familiar paradigm to a new use case, so I used a breadcrumb path based widget. A sort scheme is a progression of levels, which represent sorting criteria, and those are applied to the playlist in real time. What’s even better, sorting is not an action but a state, which means that the original sort order can be recalled at any time. One of the sorting levels is also “Random”, so almost for free this interface also implements configurable multilevel shuffle!

Multilevel playlist sorting interface

In the last weeks, which were quite busy, I implemented configurable grouping, so the user is no longer forced just to group by album or not group at all. Finally, as a bonus, I took advantage of the existing Amarok URL infrastructure to implement playlist view bookmarks. These bookmarks define a URL for each playlist configuration, which aggregates a sorting scheme, a grouping category, a playlist layout and a filtering expression, and store it in the bookmark manager. The user can then instantly apply these bookmarked states and avoid having to rebuild a sorting scheme, a grouping category, select a layout and enter a filter string manually.

Playlist view bookmarks!

Playlist view bookmarks make it much easier to control this mighty playlist, which will be landing on a GNU/Linux distribution near you with Amarok 2.2 some time this fall!

I’d like to take this chance to thank my GSoC mentor Nikolaj Hald Nielsen and the whole Amarok team for their patience, dedication and help.


Posted by on 22/08/2009 in Amarok, GSoC2009, KDE


Tags: , ,

GSoC update – The playlist sorting breadcrumb

The last time I wrote about multilevel playlist sorting in Amarok a few weeks ago, the backend work was mostly completed but the (temporary) GUI was fugly, just a bunch of comboboxes.

Not any more.

For Amarok 2.2, among other things, we are working on improving the consistency of the user experience by adding horizontal symmetry, so both the browsers pane (default left) and the playlist (default right) will look and feel similar. Those two areas already had very similar filter bars, and since a few days ago they also both have breadcrumbs.

Until recently, breadcrumb bars have been used almost exclusively in file managers, but there’s no reason why they couldn’t be used to express any sort of sequence of objects in a hierarchy. In Amarok 2.2, we are introducing this common and well understood GUI metaphor and using it to express new and complex operations. More than a month ago, Amarok developer Nikolaj Hald Nielsen implemented the breadcrumb concept in the browsers pane, where it’s used to easily navigate through the ever increasing list of Amarok’s music sources. We like to say that with Amarok 2 the world is your playlist, and the browsers breadcrumb bar is an ingenious way to bring the world’s music to the user’s playlist through our Internet services framework.

A few days ago I pushed to Amarok’s git repository a first version of a new breadcrumb interface, this one is used in the playlist. Every item in the breadcrumb represents a sorting level, or category. It doesn’t implement any kind of navigation (like usual breadcrumb bars), but so far we have found that it works remarkably well for expressing sorting schemes, which are nothing more than selections of nested objects of some kind. To express “sort by artist, and if the tracks have the same artist then by album, and if the tracks belong to the same album then by track number”, the user just has to “navigate” to “Artist > Album > Track number” in the breadcrumb bar, and the playlist view changes accordingly in real time. But what’s even better, and unlike usual “spreadsheet” sorting interfaces, this sorting method is technically a state and not an action, which means that the original track order is preserved and can easily be restored by clearing the contents of the breadcrumb bar.

The new Amarok playlist sorting interface

A few features are still missing before I can call this GSoC project “done” and I’m currently working on them, mostly sort order inversion and sort scheme bookmarking.


Posted by on 08/08/2009 in Amarok, GSoC2009, KDE


Tags: , ,

GSoC update – lasagna code

It’s been more than a month since my last GSoC status update. I wanted to blog more often, but unfortunately I had nothing shiny to show, all the work I’ve done was under the hood, mostly on implementing multilevel sorting and refactoring the playlist code. The refactor is what took most of the time and it’s still not finished. Basically what I’ve been doing is converting one kind of italian pasta into another, spaghetti code into lasagna code.  So a couple of new classes have popped up to enforce a consistent interface for all the playlist proxies and to share code, and I’ve been trying to make every proxy talk only to the proxy directly below it.

In pseudo-UML, this is the situation I’m trying to achieve, the arrow means “is-a” and the arrowless line means “has-a” or generally “talks-to”:


I’m almost there, but right now, even if the tracks are displayed sorted, they are played in the original order which makes no sense, so the next step is to make the code that handles progress through the playlist (navigators) talk to the topmost proxy (GroupingProxy). Also, a new proxy might pop up soon to cleanly handle searching, which is a pretty different concept vs. filtering that just happens to share the same GUI.

Anyway, as a refreshing break from the Playlist::*Proxy heavy lifting, I hacked together a new testing interface for multilevel playlist sorting:


Disclaimer: I’m aware that it’s ugly as hell, and that it doesn’t allow to sort by inverse alphabetic order, it’s just a temporary GUI for everyone to play with and test the sorting functionality. I’m still a few weeks away from starting work on the real thing, which I plan to implement as a breadcrumb-like widget.


Posted by on 09/07/2009 in Amarok, GSoC2009, KDE


Tags: , ,

GSoC status update – of proxies and maps

Hello again. In my introductory post I declared that I would post regular status updates about my Summer of Code work on Amarok’s playlist – and of course I’m already slacking off.

I started researching and coding towards the end of april so I have almost a month of work to report now. Unfortunately there are no pretty pictures this time because all the work has been under the hood so far.

As Amarok’s playlist uses a model-view paradigm, I have added a new proxy model between the filter proxy and the grouping proxy, so at the moment Amarok’s playlist view displays data that passes through a stack of four models (1 source model + 3 proxy models). GUI work will begin a bit later, at the moment the interface is just a combo box and a button that says “Sort!” which I use for testing. So what does it actually do right now? The good news is that multilevel sorting of the playlist kind of works: the user just has to hardcode a multilevel sorting scheme or select one of the available schemes from the combo box, click “Sort!” and the magic happens. Basically, the sorting scheme gets translated into a QList that maps all the source indexes to an ordered n-tuple, this QList is then used as a lookup table. The bad news is that sometimes the magic spell goes terribly wrong, as I still have to handle the consistency of the  map when the playlist is already sorted and the user adds, moves or removes some tracks. All the time I put into studying algorithms at the university has finally paid off big time, and I’m being very careful about the efficiency of the code – in the present state the sort proxy stuff might crash Amarok from time to time, but at least when it works it’s quite fast 😀

All this and hopefully much more should land in trunk some time after Amarok 2.1.1 gets released.


Posted by on 31/05/2009 in Amarok, GSoC2009, KDE


Tags: , ,

Hacking Amarok's playlist into submission


My name is Teo Mrnjavac and some of you might know me from my previous work on Amarok as a Summer of KDE student last year. Back then I implemented an interface for defining layouts by drag’n’dropping, which has been used for extracting tags, organizing the collection,  defining playlist item layouts and also in Kopete for configuring contact list items as I’ve heard.

This year my Google Summer of Code proposal has been accepted and with the help of my mentor Nikolaj Hald Nielsen I’m embarking on a mission to make Amarok’s playlist the awesomest playlist ever.

The full title of the project as submitted is “Finish the playlist: multilevel playlist sorting with configuration interface”, which means that I’ll mostly be working on implementing multilevel sorting, plus some other related fixes.

The current implementation of the playlist view in Amarok has become much more configurable recently, allowing the user to customize the format of each item by dragging around tokens that represent the fields of the track’s metadata. However, there’s still no way to sort these items according to the content of the fields, forcing the user to move around the items manually to achieve the desired effect. This can be tedious and impractical even on small playlists.
A playlist is a list, and a user expects a list to be sortable. In this case, simple single level sorting just wouldn’t suffice: Amarok’s playlist is much more than a bunch of lines of text.
To reach feature-completeness with the Amarok 1.4 playlist, and to conquer an important milestone on Amarok’s road to eternal awesomeness, a nifty interface is needed to sort the tracks.
So during this GSoC season I plan to deliver multilevel sorting for the playlist, an interface to configure it and configurable grouping.

If all this was TL;DR (it would probably be for me), here’s a nice mockup of a possible multilevel sorting interface that shows off my mad Kolourpaint skills. Notice the thin multilevel sorting bar under the playlist search bar. It’s simple as that, the user would click the “+” to add the next sorting level through a menu.

At the end of my GSoC work the playlist would be considered feature complete.

Last year I was a very lazy blogger and now I would like to change that so I guess you can expect regular progress reports. I have been informed that failure to comply with the blogging requirements about my work this year will result in me feeling the Amarok community manager’s Long Pointy Stick Of Doooooooooooooooooooom (TM).



Posted by on 23/04/2009 in Amarok, GSoC2009, KDE


Tags: , ,

%d bloggers like this: