|
Resurgent development work on KDevelop 4, with work on code parsing, code completion and the user interface. Support for converting the KVTML XML-based format to HTML in KDE-Edu. Support for the much-wanted feature of multiple album root paths in Digikam. Various continued developments in Amarok 2. Multiple additional comic sources for the Plasma Comic applet. Support for Kopete plugins written in Python, Ruby, JavaScript and other supported languages through the Kross scripting framework. A simple command-line application for playing media supported by Phonon. WavPack, TrueAudio and Speex format support added to the TagLib support library used by JuK and Amarok. Audio device work (utilising Solid) in KMix. Work begins on KsCD by a team of French students. Various optimisations in Plasma and Dolphin, amongst other applications. okular moves to a shared FreeDesktop.org library for PostScript format support. KGhostView finally removed in favour of okular for KDE 4.0. Code for supporting Apple OS X Dashboard applets via WebKit imported into playground (not for KDE 4.0!)
|
Nikolaj Hald Nielsen, Jeff Mitchell, and Harald Sitter write a report on the current status of Amarok 2 development:
|
Album grouping in the new playlist
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 ;-)
|
|
Roger Pixley introduces a new quality initiative for the upcoming release of KDE 4.0, KDE4-Krush Saturday:
|
Two weeks ago, Aaron Seigo suggested that anyone interested in KDE hacking and testing come in all day Saturday to #kde4-krush on irc.freenode.net and beat on the KDE 4 application of your choice until all the bugs come running out. It happened and much good came of it, which of course led to the establishment of the Krush day as a recurring tradition (at least until the release of KDE 4.0!). We welcome all who want to contribute to join in next Saturday and help ensure that your favourite KDE 4 application becomes a stable addition to the KDE 4.0 release!
This last week has seen about 70 participants, with over 70 bugs confirmed (and with 57 of those confirmed fixed already). Specific examples of issues found and fixed include:
- Broken previews in Konqueror
- KRunner freezing every time a letter was entered
- The Plasma application appearing in the alt-tab dialog
- KMix configuration dialog crashing the application
If you want to report a bug, or confirm one of the 241 existing issues, prepare yourself and join us next Saturday on our KDE4-Krush quest!
|
|
|
![[*]](/images/standard/features)
![[*]](/images/standard/other)
![[*]](/images/standard/bugfixes)
![[*]](/images/standard/optimise)