Friday, December 5. 2008From the Post 2.0.0 Git Vaults, Amarok Urls and Bookmarks
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! 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 Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
I'd like to be one of the first to say congratulations on reaching this milestone. I've been using amarok from svn for a couple of months now and it rocks like no other. You guys deserve a party (and then some) for all the work you've put into it.
I'm just wondering about any info on supported media devices of amarok2. Amarok 1.4 used to support the rio karma. Might that have been kept? Any chance we'll see more work in that area, ala bug# 155877? Awesome work!
Not for 2.0. Amarok2.0 will support ipods and mtp devies. The rest will come later.
Unfortunately no, but the framework exists to add it in at a later time if someone wants to.
The above link amarok://navigate/service/Magnatune.com/artist-album/artist:"Brad Sucks" predictably broke at the quoting right before Brad, making the actual link appear as only amarok://navigate/service/Magnatune.com/artist-album/artist:
Hope you can fix that, and possibly support standard URL encoding for cases like this. ;o)
Congrats on being this close to release! Amarok 2 is an excellent player and the first media player in a while that I would say is truly innovative (that being said, until media device support works better and dynamic collections is implemented it looks like I'm still stuck with 1.4
Please just name the protocol
rok: that would make it easier for other apps to support it. Think X-Platform and X-App, please.
I don't think rok is any better, it's still doesn't make any sense for other media players to support a protocl named rok.
I do think we should try and standardize the urls and the protocol, and perhaps go with a freedesktop standard so that this becomes used more frequently.
RE: The URL structure. Do we really need the "command" part? Couldn't `amarok://navigate/service/Magnatune.com/artist-album/artist:"Brad Sucks` just as easily be something like `amarok://services/Magnatune.com/artist-album/artist:"Brad Sucks"`
The command part is mainly there because other people have expressed interest in using this system for all sorts of other stuff. For instance, I know that one dev is looking into using this system to "bookmark" locations within a track, and this will require a different url
One of the features I would like to see coming back in the next Amarok 2.1 is Audio CD support!
https://bugs.kde.org/show_bug.cgi?id=174565
Arhg!!! 8 untranslated/fuzzy Dutch strings, committed some hours too late!
However: Congrats with the new release! Already liked the beta's.
Dont playlists already provide some of this, i.e., the ability to save a number of tracks or locations and load them at will?
I love Amarok for all of its features and they have in fact become much easier to discover, but I hope you guys begin thinking about balancing features, discoverability, learnability in a way that keeps Amarok being the greatest player around.
I am surprised to be the only commenter here to think that Amarok 2.0 is not ready to be released yet!
I've been testing the svn versions and it has too many bugs. I think one or 2 more RCs would be needed before 2.0.
Please do not use the hostname field of a URL for something that is not a hostname.
It will be treated as hostname and will be transformed accordingly. Any other parts of the URL are kept unchanged. |
Amarok LinksCalendar
QuicksearchCategoriesSyndicate This BlogBlog Administration |
||||||||||||||||||||||||||||||||||||||||||

