|
Thursday, July 9. 2009
Reporting not so live from GCDS.
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.
Wednesday, July 8. 2009
Tuesday, June 9. 2009
 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)
Tuesday, May 19. 2009
 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.
Tuesday, April 28. 2009
Forward: This is a repost of the article which I wrote for a recent commit digest report by Danny Allen. Since February, Amarok 2.1 has continued improvement, so don’t take the following content as “exhaustive”.
Amarok 2 marked the first release of the newest generation of Amarok. This marked over two years of very hard work by our entire development team was greeted with great relief by all contributors to the project for a number of important reasons. As developers, we were keen to get our software out the door to users on a larger scale than simply beta quality software. We craved the feedback from the masses to improve Amarok and to get out the feature freeze that seemed to never end. More than that, all developers had great plans for implementing new features and reviving loved functionality that was temporarily removed during the overhaul.
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.
Monday, April 27. 2009
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.
Monday, April 27. 2009
 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.
Friday, April 3. 2009
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!
Friday, March 13. 2009
For the last four days I’ve been trying to implement cover art support for iPods in Amarok 2.1. I’ve reached desperate measures here, appealing to the wider public for any hints that might be available.
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:
- There is only one version of libgpod installed (0.7.0), self compiled with gdkpixbuf support
- Gtkpod was also self compiled against libgpod 0.7.0
- The libgpod guys have been very involved but can’t provide any answers
- 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
- 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.
Sunday, February 15. 2009
A community service announcement:
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?
Thursday, November 6. 2008
Most of the Amarok crew are on Twitter - it’s been said before.
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  .
Thursday, October 30. 2008
If you’ve got a mailing list dedicated only to bugzilla traffic, you might find these rules useful to filter out any spam. Since the Subject field of these lists are so rigid, we can obviously tell which emails are spam.
Use the following rules in your mailman config:
Rule 1: Discard any emails flagged as spam
matches? ^X-Spam-Flag: YES
action: discard
Rule 2: Accept any emails which fit our [BUG 1234..] subject header
matches? ^Subject:.*\[[bB][uU][gG]\s\d*\].
action: accept
Rule 3: Discard or hold the rest, they’re probably spam!
matches? ^Subject:
action: {hold,discard}
Monday, October 27. 2008
Amarok 2 is really gearing up to become a great piece of software. We are all are frantically trying to find any time we can steal from our busy schedules of work, study, and good-times to put some of that extra special attention to detail and polish on the application.
This week I finalised the third revision of an importer tool to recover your beloved statistics, scores, ratings, lyrics and album art from an Amarok 1.4 installation. After a rather draining and involved process starting off with Ruby, moving to QtScript (javascript) I finally cut my losses and have implemented an extendible framework directly in the application with c++. You’ll be able to retrieve your stats from any of sqlite, mysql or psql database backends. Throw in a wizard, some multi-threaded goodness and an output logger, and we’ve got a snazzy new tool for your convenience.
I put a bit of extra effort in on the side to make sure that the tool won’t go to the land of bit heaven after the release of Amarok 2.0, and incorporated a pretty nifty infrastructure to allow implementations of arbitrary importers. I’m thinking iTunes, Rhythmbox, Banshee, WMP, Winamp et al. If you’re looking for easy entry into KDE development ask me how to write an importer.
There have also been a plethora of other significant updates to Amarok, such as:
- Totally reworked play list subsystems which respects groupings, dragging, extended selections, viewport updates, styles.
- The status bar, it works!
- Locale aware sorting in the collection browser. No more unintuitive placement of your Åwesome ?usic ?itles.
- More reliable lyrics retrievals.
- Snazzy new icons.
Stay tuned for Amarok 2 beta 3 which we’ll have out in the wild very shortly.
Monday, October 6. 2008
You may have already noticed, that we have released Amarok 2, beta 2. This is a very exciting release for us as we have put an incredible amount of effort into features and bug fixes. This release pushes most of the significant work which was discussed or achieved during Akademy, such as changes to the Amarok core which will bring significant stability improvements and improved user experience.
We’ve made a rather large change with the removal of SQLite as our database backend, opting instead for the MySQL-embedded platform. As I know that many users might not be able to rationalise this change, allow me to explain. MySQL-embedded provides users with the performance boost of a standalone server without actually needing to run the server and without needing to bother with the rather complex procedures of intialising a database, users and permissions. It was also important for us to only support one database backend as we were constantly plagued with problems across different databases. Using MySQL-embedded will thus make it very easy for us to support standalone MySQL servers (in the future) for those that already have these services running, or may want to share databases over a network.
Notable mentions include improved scripting support, the return of lyric fetching and incremental scanner support. It’s important to remember that Amarok 2.0 will not be at feature parity with 1.4 as most of the code base has been rewritten. Many of the features that are not present have simply not been reimplemented due to lack of developer time, or we are unable to complete due to current technical limitations (such as equalisers, visualisations, replay gain).
We hope you enjoy this release.
Friday, October 3. 2008
A quick service announcement:
The Amarok project has started it's annual fundraiser campaign Roktober. We're hoping to raise a staggering €10,000 - for server costs, developer hardware, travel costs, expo and trade show exhibitions, developer meetings.
For every €10 you donate, you'll go into a draw to win an iaudio7. This year we have two grand prizes and we will also give t-shirts to 4 second chance winners.
Also, please digg it.
|
