freespirit

Back in part 1 I showed a few of the things that will make it into Amarok 2 at some point ( likely for 2.1.0 ).

Today I want to show you another thing that I only recently started working on. Its another somewhat controversial part of Amarok 2, namely the playlist.

Since we first started showing screenshots of where Amarok 2 development was heading, some people have been unhappy with our idea of a new and improved playlist ( and have been extremely vocal about their displeasure ). We have tried reassuring them that the playlist would, in time, come to encompass many of the things from Amarok 2 that they were missing as well as a whole lot more, but it is always hard to communicate such ideas with no screenshots to back them up.

So, since I just today got something running that finally demonstrates some of these ideas, I rush to blog it! Please note that this code is still at a very early state and that there are a few rendering inconsistencies visible that will get sorted out before this ever makes it into trunk.

What this new code does, is basically make the way each item in the playlist is rendered completely configurable. how any rows there should be, what elements ( title, album, artist, score, ... ) should be shown in each row, how much space each element should be given and so on is all fully configurable. (Configurable from a code point of view, the ui for actually configuring it does not exist yet... ). So for instance, configured to mimic the current playlist layout, it might look like this:



That looks a lot like the current playlist, only slightly uglier because of some of the rendering issues I mentioned earlier. Messing a bit with the ( for now, hard coded ) config for the playlist and adding a few elements to some playlist item types we can create something like this:



Here we have added the score to all body item ( tracks in an album group ) and given the title its own line for single track items. Finally, as the grand finale, for people who prefer the Amarok 1 playlist, it is possible to do something like this by making all items have just one line ( and the album header none, thus making it invisible ) and use the same config for body and single track items:



For dramatic effect I have also hidden the context view! Add to this some decent sorting controls, and basically all the functionality from the 1.4.x playlist can be brought back. And yes, some of the items are "jumping a bit", this is one of the rendering issues I mentioned.

I think this playlist will end up being much more configurable and powefull than the 1.4.x one ever was, even if this was not immediately visible in the Amarok 2.0.0 release. But as we have said many times, Amarok 2.0.0 was just the beginning. Now comes the hard part, creating a sane ui for letting the user configure the playlist layout. Luckily, Dan has the concept of how this will work well under control.

First of all, just to get the terminology straight. In this post, I define a filter as something that limits what you actually see in a view, and a search as something that selects items in the view without affecting other elements.

Amarok 1 style playlist filtering.

Since Amarok 2.0.0 was released, one of the frequently mentioned Most Missed Features (MMF) is the Amarok 1.4.x style playlist filtering.

The filtering in Amarok 1.4.x is indeed very powerful, but it also suffers from a number of usability problems and is actually sort of a weirdly placed feature as the collection is where advanced filtering is meant to take place as it will always haver more powerful mechanisms for advanced filtering.

That said, we are very aware that there needs to be a simple way of locating content in large playlists and perhaps even limit the playback of tracks to a subset of what is in the playlist in a non destructive way. Inspired by the progressive searching in apps like Firefox (and indeed many of the KDE 4 applications) we decided to try this out instead. So, hidden away in a small cabin in the very dark woods, far away from streetlights and traffic, I decided to have a go at this.

Amarok 2 style playlist searching.

This morning I committed the initial version of a rather advanced playlist search feature. At its very core, it is just a progressive, as you type, search. This means that as you type, the first track that match the current search term will be selected (and the playlist scrolls to it). Next and previous buttons then allows you to jump around in the tracks matching the search (These really need to get some keyboard shortcuts... Working on that one). The search edit gives immediate feedback on whether there are any matches or not, in the same way that, for instance, the KDE 4 version of Konsole does. By turning the search edit a different color and disabling the next and previous buttons. Now by itself, this is useful, but not super powerful, but this playlist search has a few additional tricks up its sleeve. It is possible to specify which fields should be matched against when typing a query. This is changed by clicking off the fields in a small drop down menu.

Currently it is possible to search any combination of track name, album name, artist name, genre name, composer name or year, and I have a few more ideas for properties to search that i am going to add. It is also possible to "lock" the track progression to only play tracks that matches the current search term. This is toggled using the same small drop down menu. It provides a very convenient way of just playing a particular artist from your all time favorites playlist or any number of similar use cases. Currently this only works when using "standard" or "random track" playback modes however, and I am still pondering whether it actually makes sense for any of the other progressions modes, such as "random album". All the options from this drop down menu are of course stored in the config so the options are persistent across sessions.

We are aware that some people will still miss the old style filtering and that this is not the same thing. We do believe however that a search makes more sense in the playlist than a filter, and that this satisfies many, although not all, of the use cases that the old filter did. Going forward, it might also be possible to add other features to the search, such as selecting all matching tracks, or exporting matches to a new playlist, if there are use cases that support these additions.

One thing I am still pondering is if the filter bar should be visible at all times, making the feature very easily discoverable, or if it should only appear when the search keyboard shortcut is activated....

As mentioned, I committed this code this morning, and baring any major issues turning up, it will be appearing in Amarok 2.0.1 which should be released shortly after new year if all goes well. If you cannot wait that long, it should be appearing in the nightly builds shortly, and failing that, there is always building straight from svn!

Yesterday, after nearly 2 years of hard work, blood sweat and tear, we finally released Amarok 2.0.0. Reactions so far have been mixed, but this was no worse than we had expected. We are drastically reworking an application that many people are very fond of, and taking it in a very different direction, and for some people this will not be the direction that they had preferred. Also, some of the features that some people depend on in the 1.4.x series are not yet in Amarok 2, and while we have tried being very upfront about this, apparently it is still a big shock to some.

One of the things that has been most controversial so far, is the new look. This has spawned a number of mockups from people who have ideas for way to improve Amarok. Some of these are really good! See these pages for some examples:

http://kde-look.org/content/show.php/A+Media+Player+for+KDE4?content=94472
http://www.kde-look.org/content/show.php/Amarok2+Look+and+Feel?content=93854

From the comments on some of these mockups, its is quite clear however that we face somewhat of an issue of understanding. Comments like

I like your mock =)
It looks 100 times better then current amarok which has usability = 0.

BUT
I can almost guarantee that this will never happen...
Amarok developers are quite "strange" people... It's their way or the highway.
Hey if they were not then amarok 2 would not bad as it does today. =/

and

Amarok already has chosen a look and at best changes now are going to be evolutionary rather than revolutionary.

besides being quite degrading to all the people who have worked very hard on Amarok 2.0.0, to me indicates a profound lack of understanding of the amount of work it takes to actually turn a good mockup into a working look for an application, especially from the artist.

So while we get really nice mockups from time to time that we would love to implement, few of the artists so far has been willing to stick with us to do the actual hard, boring and repetitive work required to actually make it happen. Hence the term "Drive-by Mockups".

So is there a point to this rant? I am not sure. I certainly dont want people to stop making mockups as some of these contain really good ideas, but I would ask people to not attribute to malice or stupidity from our side what is simply caused by few artist having the time and being willing to follow up on their mockups.

Amarok 2.0.0 has been tagged! Short of any really bad bugs showing up the release will be upon us shortly, just as soon as the packagers from the different distros have had a chance to do their thing! This release has been nearly 2 years in the making, and all of us developers have shed blood, sweat and tears trying to make Amarok 2 live up to the vision that has driven us all along. Overall, I am very pleased with the result. Some people will initially miss their favorite feature from 1.4.x but Amarok brings so many new thing to the table, that at least for me personally, it is a far superior player to 1.4.x already.

But this blog post is really not about Amarok 2.0.0 at all. You can be sure that his will be covered in great detail, reviewed, tested, loved, hated, praised, FUD'ed, criticized (both constructively and not so...) and all that in the weeks to come. What I will try to do here is give you a small glimpse into the future, the great big world beyond 2.0.0.

You would think that having worked on Amarok 2 for 2 years, we would need a break. But actually, it seems that nearly all developers have big projects that they are ready to start on as soon as the feature freeze is lifted, or are already happily hacking along on new stuff in Git branches. I currently have 3 such branches containing post 2.0.0 features in different states of completion, and in this blog I will show some of the stuff I am working on in one of them. Remember that all this stuff is fresh raw and untested from my own git branch and may change in any number of ways before it ever gets near a release

Amarok Urls

The idea behind Amarok urls is to give amarok a concise way of referring to different "views" within the application and allow these views to be easily passed around, shared and stored. An Amarok url is simply a url with the protocol "amarok" followed by a command and a series of arguments encoded as a url. For instance "amarok://navigate/service/Magnatune.com" is an Amarok url that will cause the Magnatune service to be shown ( if enabled ). In my git branch, the "navigate" command has been fully implemented, and you can navigate in all the browsers. Amarok also installs a protocol handler, so clicking the link above will startup Amarok ( if not already running ), and make it show the Magnatune service. Actually the navigate command supports additional arguments, so a more complex url could be constructed that would not only show the Magnatune.com service, but also set the sorting mode and filter. So If I wanted to direct you to one of my favorite Magnatune.com artist, "Brad Sucks", I could write a url like this: "amarok://navigate/service/Magnatune.com/artist-album/artist:"Brad Sucks"". In this form, these urls are already useful. For instance, they provide a very easy way for context apples to provide "guided searching" in the browsers where clicking on an album cover in the context view actually browses to this album in the browser. Additionally they could be used if you want to blog about a cool new artist in one of the services, as you could simply provide a link similar to the one above, or online services could provide a "browse in Amarok" link for their content. There are many possibilities! But the concept can be taken further by expanding it into

Bookmarks

A bookmark in my git branch is actually exactly the same as an Amarok Url, but the context in which it is used is different. A url is most often something that comes from an external source, whereas a url that is used internally to store a favorite view is what I call a bookmark ( I am very open for suggestions for a better terminology ). So without further ado we have the first screenshot of the evening, the (very much work in progress) "Bookmark Manager" applet:



This applet allows you to grap the url of whatever state the browser is currently in. So browsing somewhere, setting a view mode and entering a filter, and then pressing the "Get Current" button will generate the corresponding url. The manager allows basic operations such as saving, renaming, deleting and of course applying (activating) bookmarks. I have not quite gotten drag and drop organization working, but that will be possible as well. This is also nice if you want to share a cool view with someone, as you don't have to think about how to manually construct the url, but can simply press "Get Current". Oh as i am sure some people will ask why I made this an applet and not a browser, the reason is simply that since these bookmarks actually "work on" the browser, it makes sense to be able to play around with the bookmarks without the manager getting hidden as soon as you activate a bookmark as it navigates somewhere else in the browsers.

Then someone came up with a use for this that I had not considered. A wish list item on our bugzilla asked for a way of bookmarking content for later. The example given was the user finding a cool Magnatune.com album, but not having time to actually purchase it right now. While the bookmark manager can certainly be used for this, the fact that you have to manually type in the query to isolate the album or artist that you are interested in is less than optimal. So today, during a very long train ride, I came up with this:



Now all albums and artist in all collections (using a nice system I actually implemented to allow the last.fm service to add the "Play Similar Artists from Last.fm" action to all Artists in all collections with out hard-coding anything) have an option to bookmark them. This system does not work in all cases for all services yet (mainly because filtering does not work exactly the same way in all services), but for the local collection, Magnatune and Jamendo, it works perfectly already

This will likely make it into Amarok 2.1.0, so even though Amarok 2.0.0 is, in my opinion, already a great player already, development is in no way slowing down, and we have 100's of really cool ideas that we will work on implementing in future versions.

I have other git branches with post 2.0.0 features lying around, so depending on the response to this post, I might blog about those later