Last night after our first day of hacking a group of intrepid developers had tapas.

We ate way too much and followed with some great ice-cream. Try the dulce de leche.

As most of our event destinations have been within walking distance, we figured we could also walk to the Collabora sponsored party.

Map: check.
GPS: check.
Location close: check.
Sugar induced enthusiasm: check.

It soon became obvious that walking to the golf course wasn’t as simple as we’d first hoped. We had to jump a few highway barriers.

And we clambered along dirt shoulders.

We played frogger with Spanish traffic, and then decided it was time to head back to find a taxi.

We made it and went straight the the bar where the fun was flowing.

Danimo and Chani in serious conversation.

And Thiago decided to recite some shakespeare to us.

And Markey was eyeing off the bar.

Más fotos

So I have tickets to Akademy 2009. I’m flying Sydney – Hong Kong – London – Madrid – Las Palmas, and I’ll try not to whinge about it.

But typically, more things gone wrong: the GCDS “travel agent” decided to lose my booking and now I don’t have anywhere to sleep. Anybody about that also needs somewhere to sleep or would like to thrown in an extra mattress into their room? (I’ve got a wonderful sense of humour if that makes the deal sweeter)

You might know that Akademy 2009 is going to be held in the Canary Islands in July. It’s going to be fantastic and fun and hot and warm and we’ll be absolutely spending time at the beach rather than listening to some technical mumbo jumbo.

But I have to say – it must be one of the most ill conceived locations to put a conference. It’s far from the US. It’s relatively far from Europe, and it’s fucking far from Australia. The only people that will have a short trip will be those in Western Sahara.

My tentative flight route is ridiculous – via Singapore, Milan and Madrid. That’s 3 stop overs. 38 hours of travel time. Plotting straight lines from stop to stop puts the trip at a whopping 19514.39km. Just so you know just how far this is: it is 32% of the radius around Saturn. I’m not even going to tell you the cost.

One of the most challenging parts of the transition to Amarok 2 was refactoring the innards of the application to make it more scalable, robust and flexible for future improvements. In many ways, this was one of the biggest technical problems of the 1.4 series — it did not scale well to new features.

Following the release of Amarok 2.0, we received mixed reviews from critics and users alike. Many writers praised the user interface overhaul and infrastructure changes, such as Ryan Paul in his article over at Ars Technica:

“After extensive testing, I’m convinced that Amarok 2 is a major improvement.”

Jeremy LaCroix of linux.com reported a fair review and noted many aspects of Amarok 2.0 that left much improvement to be desired. As a team, we’ve concentrated on many of the concerns that have been raised in reviews and in forum posts by evaluating importance and relative cost of implementation. Examples of requests which we have brought back for the 2.1 release of Amarok include: track queueing, replay gain support, playlist searching and playlist layouts.

We were well aware that with the release of Amarok 2.0, it would be impossible to match the feature set precedent that had been set so high by us in previous releases. To put it simply, we felt that Amarok as a project would have been detrimentally affected by indefinitely waiting to reach feature parity with the 1.4 releases. We were forced to take a stand and simply tell ourselves to wait to implement them. Trying to incorporate the features that are the most useful and important is a difficult task when there are often twelve different responses between five people in a discussion — one man’s garbage is another man’s treasure. That said, we did elect to remove some features from Amarok entirely – mainly for technical reasons (multiple database support for example), some for lack of developer resources (moodbar), and also some for usability reasons (such as tabular playlist design – remember, we’re the experts!).

Initially, the responses to the announcements of dropping features was exactly what we expected — there would be outcry. We expected this for a number of reasons: only the disgruntled speak up, and most readers wouldn’t initially understand how they could adapt to new paradigms. We dealt with this by trying the best we could to deal with the fallout by responding to each individual complaint or worry, but obviously we couldn’t get to all of them (and some were not worth wasting time on). I feel that we’ve managed the community quite well, and that the community has been good to us too by mostly understanding our position and being patient with the developments. Honest communication through blogs of missing features that would return was appreciated by users, and we’ve done our best to bring back the most requested for 2.1.

Many users have decided to stick with Amarok 1.4 for the time being until they see a better set of features implemented. And quite frankly, that’s okay with us. On the otherside, there are users who are keen to try out newer development features but are uncomfortable messing with their system compiling unstable development versions. Neon, our nightly build package service has been praised and exceptionally useful to give users cutting edge builds with no hassle.

Finally, it seems to us that most of our users have noticed the rough edges of the graphics which are being used in the application (specifically the context view). We realise that this does need some work and are trying hard to work with artists develop some great visuals. Also we’ve tried to improve the usability and performance of the context view by providing only a single containment rather than four, and better widgets to use.

If you’re interested in seeing a tour of some of the new (and revisited) features which are coming to Amarok 2.1, take a look at this great overview.

Recently I began using QtCreator to try and do some development on Amarok. During my day job as a Java developer I get to work with tools like Intellij, which is a great IDE when you can put aside the problems of Java GUI apps on Linux. For a long time I’ve been using vim for my KDE development which has been more than sufficient, but lately I’m craving some of that productivity win that a fully fledged IDE can give.

Today I’ll show you how you can set up your KDE application in Qt Creator and use it’s interactive debugging to enhance your development speed. I’ll assume that you have an existing KDE project and you’re using Qt Creator 1.1, and I’m not going to do any whining about bugs and that rubbish.

Firstly, you’ll need to open a project. It’s as easy as File > Open and then find your CMakeLists.txt file. Your project should be parsed and opened. While we’re at it, let’s make sure that our compilation is optimised to use all of our computational power. Visit the Projects tab, select Amarok and under Build Steps add -j5 (or similar) to the additional arguments input.

Now let’s get straight to the debugging. Back in the Projects tab, find the Run Settings panel and add –nofork as an argument. This tells the application to run without forking so we can attach to the process without worrying about magic foo computer stuff. I’d also recommend enabling the debugging helper which can be turned on in the settings window (under debugging).

Press F5 to start the debugging the application. Either before or during, or after the application has started up, set breakpoints in the application by clicking on a margin in a source file. You’ll see a little red icon display.

When you hit a breakpoint, the application will stop as it waits for the debugger. Here’s where using the interactive debugger wins over using gdb directly. You can easily see objects in the stack and navigate between callers. You can easily switch between thread dumps, and view local variables. You can set watches and not have to worry about remembering all the fiddly commands and what you are and aren’t watching. Stepping over and into functions is a breeze with the keyboard shortcuts (F10 and F11 to step over and into respectively).

This quick guide should hopefully be applicable to any KDE app, not just Amarok. I’ll let you discover the intricacies of using gdb as a debugging tool from within the IDE.

A few weeks ago I started working on improving a few little niggling problems that I’ve been having with Amarok recently. Here’s a brief overview of what I’ve done.

Prettier Collection Browser
A image is really the best way to show this:

You can see that each collection uses more space to make it easier to find and select/expand, a descriptive icon and the number of tracks in each collection.

Better Compilation Support
Various artist handling has been poor through Amarok 2, but we’re looking at remedies. Thanks to Michael Quinn, we have a patch that already vastly improves the detection of compilations during a collections can. You can see these albums in the screenshot above, too.

Improved iPodding
This mainly involves artwork support – writing and reading artwork to and from an iPod works nicely now. So, if you use your iPod as your main collection, you’ll be able to see your artwork now. There’s still no way to do a batch artwork update, but that’s certainly on the cards.

I don’t like to tease too much — so to save you asking, Amarok 2.1 beta 1 should be available for widespread testing within a fortnight. Lap it up when it arrives!

Here’s the problem. Any returned GdkPixbuf objects from libgpod when called from within Amarok are invalid — they’re either garbled junk, null, glib asserts, or libgpod throws an assertion claiming something or other:

(process:26875): GdkPixbuf-CRITICAL **: gdk_pixbuf_scale_simple: assertion `src != NULL' failed
(process:26875): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
(process:16782): CRITICAL **: unpack_UYVY: assertion `width * height * 2 == bytes_len' failed

The most bizarre part of it is that the exact same code works perfectly when called from within one of libgpod’s unit tests, and artwork retrieval works fine in gtkpod.

A few things I know for sure:

1. There is only one version of libgpod installed (0.7.0), self compiled with gdkpixbuf support
2. Gtkpod was also self compiled against libgpod 0.7.0
3. The libgpod guys have been very involved but can’t provide any answers
4. Both gtkpod and Amarok link to the same versions of libgpod and gdk:
   $> ldd /usr/lib/kde4/libamarok_collection-ipodcollection.so
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0
libgpod.so.4 => /usr/lib/libgpod.so.4
$> ldd `which gtkpod`
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0
libgpod.so.4 => /usr/lib/libgpod.so.4

5. Could it be a race condition somewhere? Perhaps, but as I see it, the code is only ever called from the Qt GUI thread.

Here’s the snippet of code: http://pastie.org/415144

Can anyone provide any insight to this problem? I’m going bananas trying to solve it.

Update: Problem solved folks! Turned out to be a misuse of the libgpod api – calling itdb_device_read_sysinfo() kills the artwork structs which have been already initialised. The blame game lies equally on Amarok (for incorrect usage) and libgpod (for poor documentation and unexpected results). Good news is that the grand folks upstream at libgpod have been notified and they’ll be improving their API and docs.

World of Goo has been released for Linux.

It’s a wonderfully enjoyable puzzle game which has been awarded multiple awards across for the PC, Mac and Wii versions – and it has recently become available for Linux. It’s cheap, DRM & region free, and if you buy it you’ll not only be supporting indie game developers but also the gaming linux environment.

Why not try the demo?

But if you’re a little more excited about developments in Amarok as opposed to the lives of the developers, you should checkout the official Amarok twitterer. You’ll be able to follow announcements, updates, cool tips, links, and we might throw in a few early announcements there .