KDE Commit-Digest
Earlier this year, Ian Monroe did a lot of exciting work on laying down the basics of a new kind of playlist for Amarok 2 as a part of his Google Summer of Code project. The new playlist aims at being much more graphical in its expression, and allow for greater customizability of the info displayed for each track. Also, the old column based playlist required a large amount of horizontal space, and one of the goals o the new design was to make the playlist less wide. One response we heard quite a bit in connection with the development screenshots we posted, was the each track in the new playlist took up too much vertical space. So in an attempt to overcome this problem in many use cases. I experimented a bit with displaying an an album as a cohesive group. This has the advantage that you only need to show the information common to all the tracks in the album once, allowing each track to take up much less space.
Upon posting the first, quote rough, preview screenshots of this, some people were inspired to come up with graphical mockups of how this could be made to look. One of these was so good that we decided to try and use it as a base for the general look of the new playlist.
Doing the actual code for keeping tracks of album groups when moving, adding and deleting content took a few tries to get right, but the result is turning out quite promising. I have created the following video showing the current state. Keep in mind that this is still under quite heavy development :-)
Scriptable services
One of my long running pet projects (that has been rewritten a few times by now) is the scriptable service framework. As I started working on a general framework for adding services to Amarok2 (the framework that currently hosts the Magnatune, Jamendo, MP3Tunes and Shoutcast services), I started playing with the idea of letting people add their own services and content using scripts. This would allow people to add content that we either do not have the time or resources to add to Amarok ourselves, or content that is too "narrow" to warrant the inclusion in the default installation. Or, and this is the part that really excites me, great content and services that we have simply not thought of!
The basic idea behind the scriptable services is that you run a script to create a service. The newly created service then calls back the script to add he root content elements when the service is activated. Each element is created with the knowledge of what it needs to tell the script to have it populate that node when it is expanded. In this way, everything is lazy loaded as needed and the framework really does not care how the script gets its content (or even if it is a script or a remote application).
This is a bit abstract, and unfortunately, I do not have any screenshots I can show currently. Also, as it is not something that is in the "must have" list for Amarok 2, it might not be included in the first coming version. But it is definitely something I will continue to play with.
 |  |
Media device support in Amarok 2 is coming along nicely. In Amarok 1.4, we used KDED's MediaManager to inform us of generic file systems that could be handled by the Generic device plugin. This has been reworked and extended in 2.0 to use Solid to automatically detect and select the correct plugin for almost any (probably more than 95%) type of non-generic device out there (one notable exception being some specific Sony devices), and any type of generic device that is marked in HAL as a portable audio player. Jeff Mitchell will be working on a method to mark generic devices and file systems that are not in HAL but should be handled automatically as a portable audio player. Jeff plans to use a system that will interoperate with Banshee's method, discussions with the Banshee developer are planned to finalise these details.
After that come the devices themselves - they are not yet ported. There are a few things that need to be done first, like converting the device handling structure to use the new Meta system. But two of the devices (generic and MTP) work well enough that you can connect to the device and disconnect from it, and see a listing of the files on the device. Once the Meta system is put in place, Jeff hopes that it won't be too hard to get the devices ported over to use it, as well as the other new subsystems in 2.0.
Development tools
Amarok's old release script was basically a Ruby rewrite of our very first (bash script) version: over time, we developed it with more and more lovely Ruby code. But as always with such things, nowadays it is no more than a big messy load of crap.
Amarok 2 development seemed like the perfect time to do a complete rewrite. The new release script, which currently has the obvious name of release_amarok2.rb, is rooted in its very own framework which is aiming to provide a solution for every release-related task (may it be creating the tarball or just tagging).
The real cool thing about this framework is that by design, it is 100% modular and generic, which makes it usable for every KDE extragear (and probably also playground application). The only thing you have to do is to write the actual script which calls the functions you want to use. This is possible because everything is divided into logical parts at the file level (e.g. libl10n for everythin l10n related), as well as at the code level (e.g. InformationQuery() and FetchSource()). This way you can easily turn features off, turn them on again, trace bugs and most importantly, it makes the code better structured, hence improving maintainability and making it unbelievably easy to add new functionality.
Currently it can fetch the sources of the application, l10n-messages, docs, and also creates a ready-to-go tarball (using KDialog all over the place ;-)
