freespirit

One of the things that I have known for a while had to be done, but I had not really gotten around to, was making proper configuration pages for some of the services. For instance, having to type your mp3tunes username every time you want to use the mp3tunes service or the new ampache service. Also, it should be possible to disable services that are not used. With the recent conversion of all the services to proper plugins, I decided that it was time to start looking at this.

First of all, the neat KPluginSelector widget gives us an easy way of showing available plugins and enabling or disabling them. This makes it simple for each user to have only the plugins that are interesting to him or her shown in the service browser, and allows us to ship a large number of plugins without having to worry about the service browser becoming overcrowded. Then the only big question becomes which services to enable per default. For now, I have settled on Jamendo, Magnatune and Shoutcast. The reason for this choice is, that these are the current services usable by any user right away without requiring a account on some external server. Here is first a screenshot of the main service config page:



In this screenshot is also shown the new last.fm service that Shane King has just started working on.

For now I have written config pages for 3 of the services. Ampache, Mp3tunes and Magnatune.


The Ampache config allows configuration of any number of ampache servers, and a service will be created for each in the service browser:



For now, the only config options for the Mp3tunes service is simply to store the username and password so the service can connect automatically next time it is shown:



For the Magnatune service, I added experimental support for the upcoming Magnatune memberships. These memberships are not available just yet, but will be soon. In fact, getting these memberships ready for launch constitutes most of my day job these days. When this is done I will get to spend some real time getting Amarok2 ready:


All in all, these config options go a long way towards making many of the services more useful and less like the "developer toys" they have been for a while.

Anyone who reads any of my blog posts should know by now, that I am quite enthusiastic about Amarok2. I think our initial release, Amarok 2.0, is going to push the boundaries of what a music manager is, and how it can integrate with some of all the great internet services out there.

In this post I want to touch on something else that I have been thinking about in the last few weeks. Something that actually gets me just as exited, and that is Amarok2 as a technology platform.

This discussion has been raging in KDE4 land for a while, and the point that is often brought up is that KDE 4.0 is not all of KDE4. KDE 4.0 will be the very first version of KDE built on the KDE4 technology platform. In itself it is looking to be a interesting release, but the true potential of the underlying technology will only start to become fully realized in later KDE 4.x releases.

The same logic can be applied to Amarok. Amarok 2.0 will be a great release, built on top of some very interesting new technologies, but the full potential of these will not show through in the first release.

So what are these cool technologies that I keep going on about, and what kind of features do I envision in the future for Amarok 2.x ? First of all, I think the new collection framework by Maximilian Kossick is absolutely fantastic. It is the basis of everything we are doing in Amarok2. The local collection, portable media players and all the services are all built on top of this framework. This means that some of the neat tricks that the collection framework has up its sleeve will work for all of these. One of the really cool things that is possible with the collection framework is seamlessly moving and copying content between collections ( subject of course to some collections being read only ). In Amarok 2.0 this will be used for moving content between mobile devices and the main collection, but in the future, this could be expanded to allow things like full synching with mp3tunes, buying directly from magnatune.com to any other (writable) collection, syncing up an ampache server and mp3tunes or migrating to or from mp3tunes and any other similar service. These are just some of my ideas, and I am sure that you can dream up other ruses for this. This will also allow one of our most requested features, multiple collection support, to be implemented without compromising the design of the application.

Then there is the new Plasma based context view. While we have had little to show lately, this allows for some really nice and innovative content to be dynamically displayed. And since it is easily customizable, potentially users will be able to mix and match their own context information based on their current task.

And of course, my own pet project, the service framework which makes it easy to add new content to Amarok. It is my hope that this will attract new developers to Amarok who are interested in adding or improving services. This has actually already started to happen, with Casey Link stepping up to add album cover support to the mp3tunes service, and ending up doing all sorts of interesting work towards allowing full mp3tunes synchronization. Also, as our user base grows, it becomes more interesting for additional companies and online services to have their content added and support Amarok in one way or another. And as the services are quite independent from Amarok itself (they are now implemented as proper plugins ) there is little danger of any one company gaining too much control over Amarok, and Amarok will never become Dependant on any one service.

That is all for now. In recap, Amarok 2.0 will be great, but we have many cool ideas for 2.x that are now possible thanks to the new technological underpinnings!