There has been a lot of chatter lately regarding Amarok's switch to MySQL as its only SQL backend. A decent amount is FUD -- either by people simply pushing back against change, or by people that simply don't understand the decision. Some of it (particularly Adriaan's blog post) has been insightful and interesting, but miss the mark in terms of why this change was made. This post attempts to explain why this decision was made, what it really means for you the end-user, and why you should have a cup of tea and relax.

I want to point out first that I said that MySQL is going to be Amarok's only SQL backend. A2's collection system is very powerful. Just take a look at how varied music sources from Shoutcast, Jamendo, Magnatune, Ampache, MP3Tunes, as well as local sources like iPods and your local file system, are treated as equals in A2. A collection is a collection, and is limited only by what capabilities it advertises it can support (and of course, it can supply its own custom capabilities). It's not currently enabled, I don't think, but there's a Nepomuk-based collection option too. So take heart -- this change only affects Amarok's internal SQL collection, and not other sources (although those sources can store information in the SQL database if they wish to cache information).

Since I mentioned Nepomuk, it's time to discuss another common question/demand/complaint: KDE has this nice Strigi-Nepomuk thing going on...why aren't we using it for scanning music and storing information? There are a couple main reasons. The first is that Strigi and Nepomuk are optional, not required. We can't rely on the user installing them, and even if they are installed, we can't rely on the user to configure them properly (remember that we're going cross-platform, making it even less likely). The second reason is speed: Amarok's custom collection scanner is extremely fast and pulls out specific pieces of information with TagLib. Strigi is, by comparison, very slow (it calculates hashes of all files, which means it needs to read the entire file) and pulls out less information. On a local hard drive, it may not be a big issue, but it sure is a huge issue when you throw networked storage into the picture, which is a very common scenario. I've also heard, though don't remember specifics, that querying and such through Nepomuk is rather slow, compared to a normal SQL database.  Regardless, though, remember that when the Nepomuk-based collection is finished, tracks sourced through a Nepomuk-based collection will have their metadata changes saved back to Nepomuk. So, it's not that the SQL collection is in place of Nepomuk -- they are entirely independent.

With those topics out of the way, on to the meat.

First, it is important to understand an important pair of facts. Number one: we are not database guys. Sure, we can store data in them, and more or less come up with a working schema, but none of us are gurus/wizards/jedis/etc. This leads in to number two: maintaining three databases was driving us crazy. Every time a minor schema change was needed, it had to be coded up for all three types of databases. Modifying a schema could be trivial for one database type, and super difficult (or impossible) for another. People would report bugs that we couldn't reproduce, only to find out that it was because we didn't quite understand how one database or another behaved (or in some cases, none of the active devs were using that type). And so on. So from the beginning of A2 development (and in our fantasies during A1 development) we knew we wanted just one database.

(We did actually look at abstraction layers like QtSQL and others. I'm not going to comment on them much, as I didn't do the evaluation, but in general they were found to not be flexible enough to handle all of our needs without doing some custom SQL coding (especially in the cases of things like schema changes), which kind of defeats the point. If you want to know more/want to insist that they are, try asking eean, as I think he did the evaluations.)

Now we had to choose the type. At first, SQLite seemed like a good choice. Using transactions, it's decently fast. It's pretty stable (those that complain about odd MySQL bugs should talk to markey, as he, being the SQLite maintainer in 1.4, can attest that SQLite's had its fair share). However, there were a few problems that in the end knocked it out of the running. The first problem is performance. Although for people with small collections it performs fairly well, people with large collections that switched to the MySQL or PostgreSQL backends in A1 would report enormous speed gains when operations performing complex or many queries were performed, such as adding many entries to the playlist, scanning files, or filtering/searching in the collection. Since we want to accommodate users with large collections just as well as those with smaller collections, and since digital music collections aren't getting smaller, the speed increase for our users with large collections was quite important. Many of our developers, after the switch to mysqle (as we call it, though that's not the official name), have noticed huge speed increases in their day-to-day use of A2, so that speed increase is carrying through to the embedded server as well as the normal server. That was the first knock against SQLite.

The other blow for SQLite came for a totally different reason. Many users (myself included) have multiple computers sharing a single Amarok database. Assuming all the computers have access to the music at the same mount point (and a few other things are configured right), this allows you to scan once, play everywhere, update the same ratings no matter where you play it, and more. Even if your aren't sharing the database among multiple computers, many users want their database stored on a particular server for speed, security, or backup reasons. If you think either of these isn't a common use-case, you'd be quite wrong. MySQL and PostrgreSQL were quite happy with this workload. It's a total no-go for SQLite, simply because it's designed for a different purpose. So SQLite had two big knocks against it. K.O.

However, just as we can't rely on the user to set up Strigi/Nepomuk correctly, we can't rely on them to get their tables set up in MySQL or PostgreSQL. So we needed the database to be embeddable, so that it could just work for the user without any setup necessary on their part. MySQL, with libmysqld, had the seeds of this in the 4.1 series, it works decently in 5.0, and it's becoming fully supported (AFAIK) in 5.1. PostgreSQL, on the other hand, does not have any such thing. (They have an interesting and cool concept of their own of embedded SQL though.)

So this leaves us with -- as you guessed -- MySQL. It may not be any particular person's favorite database (although it is for plenty), and I don't know how much overhead it really has in embedded form, but it fit the bill. It's both embeddable and can run standalone on the local or a separate machine (yes, this is not supported yet in A2, but it will be). It is fast and robust for large collections. It is well understood by the development team. And most of all, it is a single-backend solution that fills all of our needs.

If you're still unhappy about our decision, I'm sorry. We try to please most and can't please everyone. But we're the ones that develop and support this thing, and so we made a decision based both upon our needs as developers and the real-world use-cases from the collective feedback of thousands of users that have contacted us over the last few years. Please remember that even if most of the comments on the Dot, or to this post, (i.e. much of the sudden visible feedback) are from people that are unhappy with our decision, it is a decision that will actually suit the vast, vast majority of our users better than the other options we currently have.

We're a project that is known for being good to our users -- we listen to them, we try to implement features they want, try to be responsive with support. It's one of the things that got us where we are today. So please, dear readers -- put some faith in us. This has not been an easy decision -- we've discussed, we've argued, we've thrown things, we've made up, we've had an after-the-make-up orgy or two -- but in the end it's what we collectively felt was the right way to go, and we feel that, in the long run, it will make Amarok even mores awesomer. Hopefully you'll feel that way too.

Continue reading "MySQL in Amarok 2 - The Reality"

Yes, i know this sounds contradictory to what markey said in his recent blog, but i felt the need to elaborate somewhat on his statement regarding the old-style playlist being gone. While yes, this is entirely true, and good riddance (as it says), this is mainly because it is far too inflexible. The new playlist is vastly superior in all ways, and i shall spend a few moments describing to the doubters just why this is so.

The most often mentioned dislike with the new playlist is, well, the new playlist - or to be more exact, the default layout used in the new playlist. In my original post of mockups of the new playlist layout, i failed to touch on the topic of the layouting system needed for it. This is really where the whole thing comes together and enables those who dislike the new fanciness to get back to using the old, 90s style playlist view.

A bit of graphics always helps with understanding such things, of course, so here you go - description of the essential parts of this below



What you can see in this mockup right at the bottom is a section reading "Available items for header". What this really means is that this is where you design the layout of your playlist. The header is what is shown in the playlist, and while the default set contains two rows of data and a piece of art spanning two rows, what is not so clear in the mockup is that you are able to add new rows and items, splitting the entire layout up in any way you want to. What this means is that if you really want to, you are able to put all the items on a single line, and the album art gets scaled accordingly.

This all depends on someone actually implementing this layouting system/manager

N.B.: This mockup also shows how sorting will eventually work in the new playlist

(Image copyright by steve)

Today on IRC a user asked the following question: "Is there a list of 1.4 features that are still missing in Amarok 2?"

As this question comes up rather frequently, I will try to shed some light on this topic here. First of all we have to make the following clear:

Not all of Amarok 1.4's features will necessarily return in Amarok 2. Many features will be ported over, a lot of new features will be added, and some old features will simply be dumped for good. Amarok 2 isn't simply a souped up version of Amarok 1, but it's almost completely a new program, and you can't expect it to work exactly like 1.x. If we wanted that, we could simply have taken 1.x and stuck a big "2.0!" logo on it, and be done with it.


Now that we have this out of the way, let's get to the meat:


Features that will likely return in Amarok 2

Visualizations

Equalizer

USB mass storage devices support

Crossfading

Stop after this track

Queue feature

Dynamic Collection

Cue file support

Collection statistics

Playlist sorting

Showing new tracks in collection

Labels

ReplayGain

Features which have been dumped. Good riddance!

Old style playlist, "Excel Look"

Support for Amarok 1 scripts

Multiple databases (SQLite and PostGreSQL)

Player Window (this can be implemented as a Plasmoid)

MusicBrainz (we have plans for something better)

Slowness with large collections *grin*

So, that's it for now. I've probably forgotten to mention some features, but feel free to add to this list in the comments section. We could then for instance compile a list on the wiki.

To control connection/disconnection of media devices, along with advanced functionality such as the stale-and-orphaned feature for iPods in Amarok 1.4, some kind of GUI is needed. One of the discussed long-term ideas is to add functionality into the root item of a treeview, which has its merits in terms of simplicity. However, imagine that you plug in your device, and want to connect to it. The collection would have to be present in a kind of dormant state in the collection browser until you hit connect in the root item. This could work, but it's admittedly odd to have a "dead" collection sitting around.

Since modifying the root item of a treeview was beyond my current knowledge, I wanted to play with plasma a bit, and it gave me more leeway, both in terms of creativity and space, I decided, at least for now, on a Media Devices applet. Some of you may have seen the ghost of this thing in svn and wondered what the dickens it is, so I'll explain to you its current functionality first, and then some of my visions for it.


This first screenshot shows the applet blank since nothing is plugged in (eventually I want it to say "no devices"). Then, for instance, you plug in your iPod (and for now, mount it outside of Amarok) and bam!


Notice a row has been added for the iPod, representing an icon for what the device is, a connect button, a disconnect button, and its mount point. Then you click the connect button and...

You guessed it, it connects (notice the iPod collection on the left). After this, you can work with it like usual, or click the disconnect button and the collection will poof away back to things as you see them in the 2nd screenshot, allowing you to eject the iPod.

The Obvious:

- This is what I would call alpha. Yes, the icons are a bit inappropriate and admittedly borrowed, but I'm sure I can get someone magnificent to create beautiful specialized icons later on (*wink wink*)
- There are still advanced features missing (like showing battery % etc.), but again, this can come later without much trouble once the base concept gets off the ground
- Usability! How will people know to go open the media devices applet the first time they try out Amarok with their device? I'm thinking to have the applet open itself on detecting a compatible device for the first time and getting focus to get the user's attention

The Vision:

So back to the stale and orphaned concept. In 1.4, you had to look at orphaned/stale tracks along with your "normal" tracks in the media browser. Now, you could have a scrollable list each of the stale and orphaned tracks, with the same functionality as before, but now it's not in your way! You can continue to browse through your iPod tracks and the orphaned/stale tracks at the same time.

The conclusion:

Well this all sounds quite well and dandy, but if I have a good idea of how this is going to work, and basic functionality for connect/disconnect is already implemented on my personal box, why don't I commit and get all the rest of the bells and whistles going? The same lame excuse: life is busy. Also I'd like to commit it in a slightly prettier more usable form with less of the obvious bugs in there.

That said, if anyone out there wants to help out with this, let me know, and I can even guide you through the code to get you going. For now though, I'll chug away at it in my spare hours.

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.

This Friday and Saturday I attended the "new" danish open source conference Opensourcedays.dk. It is not really new, as it is actually a continuation of the Linuxforum.dk conference that has been happening fr the last 10 years, but it has changed its name and venue.

I had been invited to give a talk about Amarok 2, and we has an Amarok booth on Saturday, which is the community day ( Friday is more business oriented ). To help me man the both, Dan ( Leinir ) had come in from Aalborg, and Teo and his girlfriend Stephanie had flown in all the way from Croatia. I had invited everyone to crash at my place for a few days, so my apartment has been quite full over the weekend

My talk went well, and was fairly well visited, even though it was in one of the smaller rooms. A video should be available on their site at some point.

Unfortunately, all the community project booths was located on the second floor, and it was my impression that not that many people actually made their way up there, which was kind of disappointing, but never the less, we had some very interested visitors come ask us a lot of questions.

The following picture shows Teo and Dan busy explaining the intricacies of Amarok 2 to a few visitors:


The venue itself, the IT University of Copenhagen, is quite an interesting building, as can be seen in the following picture:


A final thing of note, and I am not really sure why this is, is that every conference in Denmark apparently have to have a model racetrack for people to play with. This one was no exception ( in fact, there were 2):


All in all it was a nice conference and I hope to return next year, even though I hope we can have our booth in the main floor instead of the second floor balcony, as that would likely attract more visitors. Also, it could have been fun to bring Mike

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.
digg_url = 'http://digg.com/linux_unix/Support_Amarok_during_Roktober_2008';

Last Wednesday and Thursday a delegation of KDE/Amarok/Kubuntu folks attended the OpenExpo event in Zurich, Switzerland. There I manned (womaned?) the KDE booth together with Alexandra Leisse, Claudia Rauch (KDE e.V. secretary), Eckhart Woerner, and Luca Gugelmann.

Here you can see a photo, showing Claudia and me behind our (rather small) KDE booth:



(That's actually two tables combined; our original booth consisted of one table. But oh well;)

We had a pretty good time presenting KDE4, networking with other projects, and generally enjoying the great catering. You don't want to miss out on the tasty Asian style food that they generally seem to serve at this event. Alex gave a talk about KOffice 2, which was really well visited; Certainly there is a lot of interest in the new KOffice release, and in KDE4 in general. A video of the talk should come online soonish on the OpenExpo website. And then I also helped out a bit at the Kubuntu booth, mostly by providing coffee and making sure that Kubuntu CDs were always ordered in front of the Ubuntu ones.

What makes the OpenExpo event unique is that it's actually two events in one, at the same location: For one there is Topsoft, a commercial business style expo (featuring suits), and then OpenExpo, a FOSS event (featuring us long haired hippies). It's funny to see these two worlds meet, but also interesting to observe the cultural differences.

So basically you have one big exhibition hall, and on the left side there are the FOSS guys, and on the right side the business guys. Interestingly it seemed to me that the FOSS side has grown bigger since my last visit (moving the division line a little further to the right), and now included some companies that you would not usually expect there, including Sun, and even Microsoft (no kidding).

OpenExpo/Topsoft isn't really targeted so much at end users (although there certainly are some), but more so at networking between industry members. This also becomes evident by the scheduling: it takes place in the middle of the week, when most end users have to work and can't easily attend.

Another interesting observation was that Gnome once again didn't show up. Is it just me, or are they increasingly rare to find at expos?

I do believe that my recommendations very much match the mainstream of the opinions of the key people in Linux multimedia and desktop audio. Of course I don’t nearly know everyone of the key hackers in Linux multimedia. But I do know most of those who are actively interested in collaboration, whose projects have a lot mindshare and who attend the conferences that matter for Linux desktop audio.

Lennart forgets that Amarok is definitely a contender for the most popular music player on desktop Linux today. It possibly has the most mindshare of any Linux music player project. Remember that a long time ago, Amarok supported aRts, xine, GStreamer and helix. Now we can take advantage of not needing to care about a specific implementation for an audio output device by using Phonon.

Lennart again:

“Use GStreamer! (Unless your focus is only KDE in which cases Phonon might be an alternative.)”

This implies that a developer should only use Phonon if and only if the developer is targeting a KDE application. Frankly, this reasoning is not very well formed and is shameful. Perhaps what Lennart meant to say belongs along the lines of “Developers using the KDE development libraries might want to use Phonon”.

Amarok is a perfect example of an application which uses the KDE development libraries, but is not tied into the KDE plasma workspace. A grand portion of GNOME users pro actively install Amarok on their system because it is their preferred application for listening to music. Time to pick up the slack and get with the times.

If there was a blogger award for “Most likely to make timely posts”, then in no possible world would I even be considered for the award. I could list some excuses that sound legit in my head, but the real reason I don’t feel motivated to post often (or on time) is because I’d rather spend that time in Google Reader reading everyone else’s exciting content (that was not sarcastic).

So, lets see… last time I posted I was en route to Akademy 2008 (the KDE developers conference). That was July 30th, now, a month and a half later I am back from Europe (which was amazing), GSoC is over (sad), and class has started (jury’s still out).

Current Status of the MP3tunes Amarok Service

The Good (Works)

• Browsing & Streaming
• Querymaker is as functional as possible with the current API
• Manual Downloading from MP3tunes to Local Collection
• Manual Uploading from any Collection to MP3tunes

The Bad (Doesn’t work)

• AutoSync - 80%- The code is there, however there are problems with the daemon not receiving signals from the MP3tunes’ servers
• MP3tunes playlists support - 0%- Never got started on this

The Ugly

There is one large issue I am still wrestling with. The details of the issue are complicated, but essentially it deals with the way Amarok handles remote tracks in playlists across sessions. Generally, remote tracks’ metadata isn’t cached by Amarok for use between multiple sessions. So, if you add an mp3tunes track to a playlist in Amarok, then restart Amarok and try to play that playlist the mp3tunes track is blank. Now, there exists a method for retrieving that metadata, however it was originally implemented synchronously. When you are retrieving metadata for any significant number of tracks (10+) synchronously, and each one of those retreivals is an HTTP Get request you end up blocking the GUI thread. At Akademy I hacked a way to do this asynchronously, but it is a really nasty hack. I’ve got code on my computer that implements this feature correctly, but it has the nasty habit of crashing Amarok every so often.

Between classes, marching band, homework, and other responsibilities I’m working on getting this ironed out and committed. Hopefully this will happen before the 2.0 release, because right now using MP3tunes in Amarok across sessions is slow and annoying.

Once upon a time we had the whole of KDE included in Coverity's code quality checker, which they kindly offer (offered?) for free to FOSS projects. Coverity's analysis is tremendously helpful in finding really twisted bugs, and has in the past helped to fix countless complicated issues in KDE code.

All was fine until 2008-Apr-24, when the scan apparently stopped for technical reasons. The last I heard of the problem was that Dirk is still waiting for a reply from them.

We Amarok guys are really keen on getting our code checked again. Not wanting to sit idly and wait, I have in the meantime also contacted Coverity, asking them to check Amarok 2. Sadly, I have not received any reply so far.


Does anyone know what's going on here, and what we could do to accelerate things?

Following Nuno, I'm presenting the KDE award that the Amarok Team has won. While I'm not artisticially gifted, I'll still try to give you something remotely artsy:

Please welcome: The cat (Filoue), The spider (unnamed large Tegenaria), the award (Meep), the award holder (Markey)






Thank you to everyone @KDE. We hope to redeem ourselves with a great Amarok 2

It’s taken me the better part of a month to get home, settle in and upload my photos from Akademy to the cloud. Granted, I don’t have many photos since there were enough paparazzi at the event *glares at Bart and Sebas*.

The HDR which I’ve posted here proves that you can indeed create impressive shots only using free software, as long as you have a little perseverance and know how. Maybe Uga’s blogs will get there eventually :).

The rest of the images are on flickr.

I read the Chrome comic on Monday. It goes into technical detail in describing what their justification was for creating Chrome. By and large I think they succeeded: on the whole, Chrome doesn't appear to be a case of not-invented-hereism. They really do have some different ideas of how to do the browser, both technically and in the UI.

So yesterday I knew two things: Chrome was going to be crossplatform and the 30pg+ comic that went into some detail didn't say how they were planning to do that or anything about their UI toolkit.

So after poking at the code for a bit, it comes to no great surprise that crossplatform wasn't a big concern from the start. Currently the Linux version doesn't actually run, according to its website. And their UI toolkit choices might indeed have been based on some NIHism and are certainly not the most Linux or OS X friendly. Given how easy it is to create a crossplatform app if you make the correct early decisions, this is a bit frustrating.

They use Skia, a graphics library for Android for basic image display. And they have "Chromium Views" which mostly seem to be used to abstract between XP and Vista. It could theoretically be extended and used for crossplatform abstraction (just what the world needs - another xplatform api).

And why not Qt? "Existing UI toolkits for Windows are similarly unsatisfying, with limited widget sets, unnatural aesthetics, or awkward programming models. " Doesn't jive with my experience of Qt. But I guess I'm a bit partisan.

I do think that promising cross-platform support might have been a bit disingenuous of them, time will tell for sure. I suspect that if Linux desktop users do see Chrome, it will most likely be in the form of existing browsers incorporating some of their technology or ideas.

Amarok 2 has two scripted services that are really cool. For one SeeqPod, that lets you search for any kind of music on the web and listen to it in Amarok. And the other one is LibriVox, that integrates the LibriVox service. LibriVox offers free audiobooks of public domain books. Both services are great and definitely deserve to be in Amarok 2.0.

The problem is that they were written a few weeks ago in Ruby. Now they need to be ported to QtScript as that is the only scripting language we allow for internal scripts to reduce the headache of script dependencies especially keeping the Windows and Mac releases in mind.

Among all the stuff that needs to be done before the release of Amarok 2.0 those two scripts were kinda forgotten until now and really need some love. If you want to help us get those two scripts back please let me know. Free cookies and hugs included

So I apparently haven't blogged in a month. Sorry about that, it's not that I have nothing to say, just that I'm usually busy doing that I don't really take the time to talk about it. That said, I'll still keep this short as I myself like to read short blurbs from people who aren't well-known.

Akademy. Awesome. Of course I got to meet a good amount of the Amarok people I often talk to, which was the highlight of the trip for me really. It's one thing to discuss over IRC, and quite another to have breakfast together, chat about things non-Amarok as well as Amarok in person, and in general hang out. I also got to meet a lot of other people, like Will Stephenson who donated an MTP device for development (who I met while waiting in the waffles line) [p.s. thank you so much again for it].

Most exciting stuff non-Amarok: Gallium3D... just wow, that's all I can say. Step was pretty awesome too, though my physics is really bad. Marble is exciting stuff, but in Openstreetmap there remains much to be mapped so it may be a while before it becomes truly amazing. There's more, but these are the ones that stuck out most in my mind right now.

So, Media Device Status Report. As you can see, I haven't blogged so obviously nothing has happened. Lies. MTP playing off the device is now supported, a bunch of random bugs have been fixed, and an applet is under way to deal with configuration etc. of devices. Don't worry, this is only for connect/disconnect and options and whatnot, the configuration of devices will still be almost entirely automated. I'm trying to figure out a way to make it more obvious that for media devices you need only plug in your device essentially, for it to just work. I think that I'll try to push for the Media Devices applet to be one of the initial defaults loaded, and it'll show a text like "plug in media device to play from it" or something.

Why have I been so slow at coding? The truth is I've been held in Guantanamo for the last couple of weeks. And.... again, lies. No, between random life, then Akademy in Belgium (which I spent most of my time bugfixing and socializing), and now I'm in Japan where it's hard to stay on the computer too long, I haven't been that able to. But I'll be back in the USA Sept. 2, so starting then things should pick up a bit more hopefully.

On that note, cheers from Japan!

The Amarok team is proud to announce the first beta of Amarok 2.0, codenamed Nerrivik.
Please digg it and enjoy the release notes.

If you want to meet some KDE folks, want to see KDE 4.1 in action or if you have questions about KDE FrOSCon in St. Augustin is the place to be this weekend.

Come and say hello at the KDE/Amarok booth and in our dev-room.
We have interesting talks for everyone in our dev room:

Saturday:
11:15 KDE Edu (Frederik Gladhorn)
16:30 KDE Community - How to get involved (Alexandra Leisse and Lydia Pintscher)

Sunday:
11:15 Amarok 2 (Sven Krohlas and Lydia Pintscher)
15:15 Kubuntu - A KDE desktop (Marcus Czeslinski)
16:30 KDE Grill - Ask questions about KDE you always wanted us to answer (KDE dream team ;-))

And on Saturday 15:15 Sebastian Kügler will talk about KDE 4.1 in his talk “Don’t look back” in the main track.
Hope to see you there.

Oh btw: Last year’s social event = best social event of 2007. Let’s see if they can beat Akademy this year

I should have blogged much more from Akademy, but having hardware which insisted on frequently overheating made life a little difficult. I’m still in Belgium - in Bruges actually, blogging from my N810 courtesy of Nokia. More on that later.

I’ll start by saying that l think we had very productive week, getting lots of design and development done towards our goals for Amarok 2.0. We focused heavily on critiqueing the user interfaces of the major components in our GUI: the playlist, context view and each of our sidebar browsers. In between hacking hours, Mark, Leo and myself hosted design and release-breaking-issue sessions. These have provided valuable direction and motivation to all of our developers, so you can look forward to some exciting progress as we gear up to an imminent beta (and eventually final) release!

We also brainstormed a number of post 2.0 ideas such as interface adjustments to enhance your application experience, including, but not withstanding, mobile and embedded devices. Yes, that’s right folks, before too long (hopefully) you’ll be able to run Amarok on your favourite (maybe) small form factor device. The main use case would be for remote collections and streaming, but we’re not going to shut out users who like carrying 8GB of music on memory cards.

All this talk of small form factor devices is making me drool over my N810 as I write this. Some observations: all this very slow and awkward typing makes me much more coherent; leeching off random wireless to blog has never been easier; and, the inbuilt GPS has already proven invaluable to the Amarok crew as we used it to find our restaurant when we got lost cycling through the mid-west of Belgium. Note: never cycle 15km immediately after eating a huge meal, and never let Casey on a bicycle.

Finally, a big thanks to all that made Akademy so great: the organisers, the participants, the speakers, the boffers, the paparazzi, and all the people that were responsible for either brewing, frying or coating things in sugar.

Finally back at home. Less tired after sleeping in my own bed again. Missing everyone. Caught up on stuff. Laundry still piling up

Akademy was great. Very big THANK YOU to Wendy, Bart and their team. You did an amazing job.

Akademy was quite productive. Talked to lots of people about lots of stuff. Wait for some interesting things to happen in the next weeks and months.

I took the time to talk to some of our Google Summer of Code students about their experience. I wanted to find out where we as a community are doing very well and what we can improve in their opinion. Of course it wouldn’t be of much use if only I knew this so let me share it with you:

• Everyone seemed to agree that KDE is a great community and that they felt welcome in our community. Akademy was seen as a great opportunity for the students to get to know people and it seriously helps in turning some of the students into contributors outside of GSoC. (Note to self: Find out how many of them are still committing code in 6 months.)
• Documentation!!! The Amarok team seems to be doing a bad job here :(  (Not really sure about the rest of KDE.) I need to find ways to improve this. Suggestions welcome.
• The Big Picture: This seems to be missing. Mentors should try to give an overview of the code and community and how it fits together at the beginning. Some of the students felt lost at the beginning and it took them a lot of time to get used to everything. For Amarok I created a wiki page with all the important links to websites and mailing lists for the students. Unfortunately the code overview part of it did not get finished.
• Blogs: The Amarok students were encouraged to blog about their work every week and post it on Planet Amarok and Planet KDE. Same goes for some of the students that worked on other parts of KDE. Everyone seemed to agree that this was a good thing. The feedback they got was encouraging and helpful. They felt pushed to produce something worth blogging about at the end of the week which was seen as positive and motivating. It also showed that people are interested in the work they do and that their progress is monitored.
• Branches: Working in a SVN or Git branch outside of trunk was seen as a problem. Code did not get reviewed and tested enough before it hit trunk. Those students worked too much in their own little world. Immediate testing and code review by other developers would have been preferred and a lot of problems would have been avoided. (I know there are reasons for branches but something needs to be done about this.)
• Timezones: Timezone mismatches between mentor and student made students switch their sleep/wake times by several hours. I got a few complains about this but it was always seen as a minor problem. I don’t think it is too healthy though. So maybe this should be considered next year when matching students and mentors.
• Gurus: Every single student was very thankful for having very knowlageable people in our community they could ask when reading manuals didn’t help. Even if their questions from time to time weren’t the most clever ones they got help. You rock!
• Mentor being away: Some mentors left for a week or more on very short notice. This should be avoided or a backup mentor in place.
• Students liked that they were mostly free to do what they want, i.e. solve problems the way they want and work on their own schedule.
• Mentors in general seemed to have done a good job. You rock!

Thanks everyone who had a chat with me about their GSoC. If I didn’t find the time to talk to you at Akademy or if you were not there feel free to ping me on IRC. I will make sure your feedback gets heard.

I hope a lot of our students stay with KDE after GSoC. You have done an amazing job. Rock on!

PS: Thanks to everyone who signed my Moleskine at the social event. I considered doing nasty stuff to Sebr when he took it away from me but I have to reconsider this now since it is the BEST THING EVAR and will be reminding me of Akademy for years to come.

*hug*