Amarok Blog

Entries from April 2009

Wednesday, April 29. 2009

Parley meets Android in Cairo Posted by Casey Link in ramblurr at 17:11

Comments (0)
Trackbacks (0)

I’m exactly three months into my Arabic studies in Cairo, where I’ve been taking time off university studies and Amarok development. I’ve realized that acquiring a large vocabulary as fast as you can manage is a crucial part of studying a language intensively, and thanks to the awesome KDE-Edu folks I’ve been ~~successfully~~ barely keeping up with the hundreds of new words I’m assigned per week with Parley.

The major problem I have with Parley is that I have to be in front of my computer to use it!

I know you’re laughing. That’s like saying a major fault of beer is that you have to drink it to get drunk, after all Parley is a computer program.

You’re right, just because I hardly find the time to actually use the computer doesn’t mean I should lay the blame on Parley. Technically, I should blame the denizens of Cairo and their insane traffic. Seriously, too many of my life’s hours are wasted in the smelly, stuffy, taxis of Cairo (today was particularly bad, pardon the rant).

This past weekend I ignored the towering pile of homework and whipped up a little application for Android devices that groks Parley’s kvtml2 file format, displays lessons, and provides flashcard exercises. My app is really an Android Port of the J2ME mobile application MobVoc. Michael, the MobVoc developer, did most of the hard work for me: parsing kvtml2 files into java data structures. Mad props to Michael; I definitely plan to pass along any contribute any bug fixes/optimizations I make to his code (such as sub-lessons support).

The application - unimaginatively dubbed ParleyDroid for now - is extremely bare-bones. Here is the current feature set

Pick a kvtml2 file from the SD card

Choose 1 or more lessons to practice

View flashcards of the words in the selected lessons.

Gesture support in the flashcards: Long Press marks card as known, Fling Left/Right changes to Next/Prev card.
Each practice session has a short-term memory: i.e., if you mark a card as known you won’t see it again that session but if you restart the session you will.

Arabic Support - if the 2nd language is Arabic, it will be rendered correctly on screen

The last feature is probably the most noteworthy. Android, by default does not support RTL or non-Latin scripts, but with a little Android-trickery-that-deserves-another-blog-post I’m finally able to practice my vocabulary in the back of the taxi or while walking along the Nile.

Binary and Source:

ParleyDroid Source

ParleyDroid Android Binary

Obligatory Screenshots (click for full view):

Tuesday, April 28. 2009

Amarok 2 in Kubuntu Jaunty Posted by Lydia Pintscher in Nightrose at 11:05

Comment (1)
Trackbacks (0)

Amarok 2 in Kubuntu Jaunty

Due to not so perfectly alligned release cycles, not wanting to ship a beta version and a few more good reasons Kubuntu Jaunty was released with Amarok 2.0.2. This version is still missing a few features that some users consider vital. We have made huge improvements in Amarok 2.1 beta 1, our latest release, and of course more improvements have been made since then in SVN.

Improvements and features include but are not limited to:

improved context view

customizable playlist

replaygain support

improved podcasting support

and more

For more please read the 2.1 beta 1 release notes.

So for everyone who wants to have some of the most loved features back: you can upgrade to Amarok 2.1 beta 1 with packages from the kubuntu-experimental PPA. Be aware that this PPA contains very experimental stuff that can break your system from time to time so you might want to consider deactivating the repository after you installed Amarok.

Please don’t forget to report bugs you find in the beta version at bugs.kde.org so we have a chance to fix them for the final version.

Tuesday, April 28. 2009

From the Post 2.1.0 Git Vaults, Part ... Posted by Nikolaj Hald Nielsen in freespirit at 06:46

Comments (17)
Trackbacks (0)

From the Post 2.1.0 Git Vaults, Part I: Cd Collection

I think it is safe to say that I don't cope too well with feature freezes. In order to stay motivated I have to have a few forward looking projects. These usually take the form of interesting git branches on my laptop that I hack on while way from civilization (Much of my most interesting code has been written in my parents small cabin in the woods where my wife and I often go to get away from it all a bit. While she reads I hack

In any case, back when we were getting ready to release Amarok 2.0.0, I ran a small series of blogs about some of the stuff I was working on for later releases. I decided that now was the time to continue with this.

Quite a few users have expressed that they would like the ability to play audio CD's back in Amarok 2. The reason that it was not initially ported was that none of the core developers use CD's much and also because CD playback in Amarok 1.4.x was sort of a hack, both with regards to the actual code, but also the way it was integrated into the user interface. recently, while discussing a possible Google Summer of Code project, which was unfortunately not accepted, I started thinking about the "right" way to do CD playback. And as I had a little time on my hands, I could not help myself but create a prototype. So here is what is currently possible on my laptop:

First off we start off Amarok. Notice the cool new collection headers that Seb have created:

Inserting a CD into the drive, Amarok automatically detects it and uses the audiocd:/ KIO slave to get info if possible. These tracks can then be added to the Playlist like any other tracks (as the attentive reader will note there are a few issues with the track information still):

It is possible to mix these tracks and tracks from any other collection freely:

That is pretty cool I think. But wait, there is more. Since the audiocd:/ KIO slave is all about "ripping" CD's, why not add this feature to Amarok as well. But instead of using the "ripping" metaphor, lets just integrate it with the existing "copy to collection" framework. This not only avoids having a seperate gui and menu entries for this task, but also allows you to "rip" directly to media devices or other writable collections and not just the local collection:

After selecting a collection that the track should be copied to, its time to select a format ( advanced options for this can be set in the KIO slaves kcm module which is brought up by clicking on the "advanced" button:

And finally we use the target collections organize dialog to figure out where the tracks should actually go:

While this is all still at the prototype state ( It will not be in Amarok 2.1.0 ) it already works quite well. There are a few issues left with the implementation itself and some deeper issues with the audiocd:/ slave that affects this, such as audiocd:/ not always detecting when the cd has changed and keeping the CDDB data from the last CD around. Aslo, making this work required some pretty invasive changes to some core parts of Amarok, so its is something that will need a lot of testing as it can potentially break Amarok in interesting ways that are not directly related to CD playback itself. So far it does not seem that I have messed anything up too badly though

For anyone really eager to break their Amarok, and not afraid to compile it from source, you can grab a patch that should apply against current trunk here. While feedback is greatly appreciated, I will not offer support for any issues you will have with this patch, so use at your own risk!

Tuesday, April 28. 2009

Orbitting the Sun Posted by Seb Ruiz in sebr at 05:28

Comments (0)
Trackbacks (0)

Orbitting the Sun

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

Interactive Debugging KDE Apps with ... Posted by Seb Ruiz in sebr at 10:54

Comments (0)
Trackbacks (0)

Interactive Debugging KDE Apps with QtCreator

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.

QtCreator project

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.

Debugging

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

Interactive Debugging KDE Apps with ... Posted by Seb Ruiz in sebr at 06:54

Comments (0)
Trackbacks (0)

Interactive Debugging KDE Apps with QtCreator

QtCreator project

Debugging

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.

Saturday, April 25. 2009

Amarok: A Better Media Device ... Posted by Alejandro Wainzinger in xevix at 05:12

Comments (6)
Trackbacks (0)

Amarok: A Better Media Device Experience, GSoC 2009

So I have again the pleasure of being selected for Google's Summer of Code for Amarok to scratch some very serious itches concerning media device support in Amarok 2.

Itches:

Playlist Support
More GUI Feedback, more intuitive interface
UMS(Universal Mass Storage) Support

Playlist:

Actually, iPods in Amarok already have their playlists read on connect, but at the time I wrote the code, the code in Amarok for any collection dealing with playlists wasn't at a satisfactory level yet, which I believe it to be now thanks to the work of a few people, in particular I know that Stecchino (Bart) has worked on it.

GUI:

The media devices applet seemed like a good idea at first, but it's terrible from a usability standpoint, and since the PUD (Popup Dropper) removes any possibility of dragging-and-dropping tracks onto it, for instance, it doesn't make much sense to have it. However, I understand there's plans in the works to redo some of Amarok's GUI, part of which will accomodate the previous functions of this applet, and I'll be taking advantage of that.

UMS Support:

Yes! I swear it this time. It turned out that building a new collection-based media devices infrastructure more-or-less from scratch took a lot longer than planned last summer, and I did not get to UMS. Another reason I've held back on it up until now is that media device support in general is going to get a massive refactoring before GSoC begins, to accomodate for simple adding of support not only of UMS devices, but in the future, other types as well.

Ok, now that the explanations of GSoC are out of the way, I move on to something else.

People with media devices, aside from the above, what is it you would like to see in Amarok for devices? I can list a few off the top of my head, please list more so that I can prioritize perhaps some time for this summer and beyond.

MTP Cover Support
iPod stale/orphaned scan support
Playlist synching with the local collection

Wednesday, April 22. 2009

Facts about Rosetta and Kubuntu l10n Posted by Harald Sitter in apachelogger at 17:05

Comments (0)
Trackbacks (0)

Facts about Rosetta and Kubuntu l10n

Facts

Kubuntu (needs to) import KDE's translations (+po templates, +desktop file translations, +desktop file po templates) into Launchpad's translations system Rosetta
Those translations then can be changed and/or enhanced
Changed translations don't automagically get overriden by a new upstream import but have to be reviewed by the translation team
Changed translations have to be manually upstreamed by the translator or the translation team (thus implying that one should either have direct access to upstream's po files or file loads of bug reports)
Rosetta makes new contributors contribute to out-of-date translations
Rosetta failed to properly support KDE 3's po format for years
Rosetta's interface is difficult to use
Rosetta has no clue when a package gets removed from the archives or superseded with a new major version that does not ship the once available translation template
Kubuntu's localization breaks at least once every release cycle, always as close to release as possible
Kubuntu string changes/additions don't get translated at times
Kubuntu needs to maintain patches to keep that whole construct of import-breakage-export working

Rants

Import

Having to import all main applications' l10n related data to a distribution specific tool for enhancement and bug fixing is a completely sane thing to do. Of course, if the whole process would not be bound to the build process (i.e. if it could be supervised outside the build process) it would be a lot easier to notice/track/find issues, and god knows there are loads of those (at least for KDE imports). It probably would also help if rosetta wouldn't need ages to process the data for import. But hey, what can you do, it's a bottlenecked design.

Rosetta

So, assuming that the data ended up properly in Rosetta (which is not always the case, though it arrived there ... I guess you can imagine what I'm talking about), now a nice community member can start fixing bugs or enhance the translation (to pick up on the bottleneck: if the template is imported but the po is not, there will be loads of untranslated strings ... again I'm quite confident that you see the implication here).

---
Let's use the following example:

Leon is Kubuntu user. He is speaking German and wants to help translate KDE. Being a user who actually knows about the need of translation he knows that the translations are being handled over at Launchpad. So he commands to konquer launchpad.net. Right at the top there is a link to Translations. Leon clicks.

On the translations main page he finds a link to the translations for Ubuntu 9.04. Again he follows that link.

Oh dear, what a load of red!!!!

Anyway, he scrolls down and eventually finds german.

So far so good, now Leon just needs to find some KDE application.

Hum... Leon reads kdesktop and kicker, having used KDE for quite some time he knows that this stuff was replaced in KDE 4 and is not even available in the archives anymore, so he avoids them, luckily they are fully translated anyway.

On the very same page he finds konqueror with one untranslated string. He thinks that one untranslated string would be a perfect starting point so he wants to give it a shot.

Our character filters for untranslated items having no clue what the guide filter means as there is only none or german.

The suggested translation "Textmarken" from openoffice's translations sounds about right so he applies that. For those who don't know, the KDE default translation for bookmark in german is "Lesezeichen", Leon doesn't know that, and neither does Rosetta. JohnTooray suggested "Lesezeichen" but that was almost 2 months ago, so one must assume it was not very much liked, so for the scenario's sake we will just ignore that there is already a suggestion.

Leon submits his suggestion "Textmarke" and goes on walking through >20 pages of templates trying to find more KDE stuff to translate.

[timelaps]

3 months later still no one approved his suggestions (in Rosetta someone from the managing team, i.e. the ubuntu translation team for $language, needs to approve the translation ... those poor people have to know all common translations for GNOME, KDE, GNU, $someothersoftwarestackinmain). Leon is right now pretty pissed off and decides to never try helping again.

---

I hope you see the flaws I tired to highlight, in that very simple example use. Those are mostly non-technical problems, I have talked about the technical ones so often on IRC and in various meetings that I am simply tired of repeating myself all the time.

Export

If we are super lucky someone didn't decrease the translations quality and the language teams were not too busy fighting with Rosetta's interface to not be able to approve new suggestions. At some point (post string freeze, so someone like Apachelogger, who would actually care if import and export are working correctly before that, doesn't have a chance to fix quirks before translators start working there arse off) a ubuntu langpack gets generated and spit upon the archives.

Communication

Ubuntu must be high on something since it seems pretty much impossible that Ubuntu and Kubuntu communicate just for once. It goes like that: Ubuntu does something -> Kubuntu notices it -> hell breaks loose -> Kubuntu tries to catch up -> Kubuntu barely (read: only partially) manages to catch up before release. That seems to be some kind of law of nature.

Latest example: "lets go rape our packages of their desktop file translations" which was done less than one month before release of 9.04 without any warning.

Result: Systemsettings was speaking english most of the time, so did the menu, so did loads of other stuff

Cause: The Kubuntu patch for grabing desktop file translations from .mo files was not working + the translations were not imorted + the templates were not imported + no-one ever warned us

This isn't news at all. A flickr image set is watching the progress of Kubuntu since 8.04 (though it is, with exception of 8.10, mostly tracking in-development progress, then again how much localization QA can you expect when it is horribly broken half the time).

Also if you speak german you might want to check out the latest KDE-de thread about Kubuntu's state of translation, they also had a similar one for 8.10, where they considered various crude but understandable actions in how to handle this issue. After all the KDE l10n teams probably get most of the complaints, because the user is lead to believe that it's a problem there.

Conclusion

So, finally just let me get my position straight.

Rosetta is the best example why rolling release does not work in every case
I raised my concerns about the constant issues and lack of quality coming out of Rosetta... for I think the last year or so
Most people do not speak English, and if they do as second language I find it doubtable that they do well enough to use an operating system in English
Ubuntu touts itself as believing it's important for everyone to have a computer that works in their own language, yet the project as whole (Kubuntu being part of that larger Ubuntu) fails to meet that very claim most of the time
I pity all those that have to use Rosetta in order to make their desktop not speak 2 languages at the same time, as well as those that have to live with constant complaints coming from Kubuntu users
I am deeply sorry that I can't help either of them, due to the very nature of Rosetta still not being open source
Should this crap continue I am going to leave the Project and join Debian or Fedora, I am not going to waste my time on a system that is constantly breaking due to external (meaning not caused by the Kubuntu crew) screwups
Comments on how to improve the situtation (i.e. what Kubuntu should do in order to get out of all this) are greatly, because I'd rather not leave a project I have spent most of my spare time on for the last couple of years

Tuesday, April 21. 2009

UserBase Competition Posted by Lydia Pintscher in Nightrose at 14:30

Comments (0)
Trackbacks (0)

UserBase Competition

UserBase, the KDE user wiki, is really growing nicely but certain areas are still lacking quality content. To get those into shape we decided to start a little competition. We will announce a certain part of the wiki that needs love every two weeks and then start working on it together. The top contributors will get a beer at Akademy (or another drink of their choosing at an event they attend). This is a perfect way for you to get involved in KDE and a lot of people will be thankful to find the information prepared for them in the wiki.

KOffice will be the first project for our competition. What needs to be done? Easy! These blogposts need to be transfered to the Hints, Tips and Tutorials section of the Krita page on UserBase. Of course if you feel like giving the rest of the KOffice pages some attention that is appreciated as well.

Don’t forget to log in when editing pages so we know who gets to drink the beer

Any more questions? Ask away in #kde-www on freenode or send an email to community-wg@kde.org.

Oh and of course I already have the next project lined up but I’ll keep that one to myself for now and will announce it together with the winners of the first round Let me know if you have a project you’d like to see in round 3!

Tuesday, April 21. 2009

Amarok projects for GSoC 2009 Posted by Lydia Pintscher in Nightrose at 12:04

Comments (0)
Trackbacks (0)

Amarok projects for GSoC 2009

Just like all the other cool KDE projects Amarok did of course also get their share of excellent students for GSoC this year.

Teo Mrnjavac will make the playlist rock after having worked on tagging during last year’s Season of KDE.

Sven Krohlas will give us some unit testing goodness to find all those nasty bugs before a user gets to see them.

Alejandro Wainzinger will make sure our media device support will make people happy.

I am sure you’ll do awesome work! I hope I can soon add the names of those who are going to take part in Season of KDE (and another super cool thingy we arranged which I can’t yet talk about) to this list.

Thanks to Google for running GSoC and making this possible.

Monday, April 20. 2009

Announcing Season of KDE 2009 Posted by Lydia Pintscher in Nightrose at 15:10

Comments (0)
Trackbacks (0)

Announcing Season of KDE 2009

Accepted students for Google Summer of Code 2009 have been announced and we are very very happy with the ones we have chosen to work with us this summer. Congratulations to all of you!

Just like in previous years, we have been overwhelmed by the number of very good proposals we received for KDE. Unfortunately we were not able to accept all excellent students as the number of slots is of course limited. We would, however, like to offer every student who would like to work on his project outside of GSoC the opportunity to do so. We are happy to announce Season of KDE 2009. Last year SoK students did an awesome job and some of them have even been accepted for GSoC this year. We will provide you with a mentor and we can manage to do something about the T-shirt as well!

So students: please don’t forget that not being accepted for GSoC doesn’t mean you are not qualified/cool/good enough to work with us. It most likely just means we would have loved to accept you but couldn’t.

If you feel passionate about your proposal and would like to work on it outside of GSoC with a mentor by your side please contact us at kde-soc-mentor@kde.org and we will work out the details together.

Überhang, surplomb, strapiombo., originally uploaded by darkmatter.

Monday, April 20. 2009

Free Developer Sprint for North ... Posted by Jeff Mitchell in jefferai at 09:34

Comments (0)
Trackbacks (0)

Free Developer Sprint for North American GSoC students!

For anyone that hasn't seen the Dot story, check it out.
Continue reading "Free Developer Sprint for North American GSoC students!"

Wednesday, April 15. 2009

The smallest unit of freedom: a fellow Posted by Myriam Schweingruber in mamarok at 13:19

Comments (0)
Trackbacks (0)

The smallest unit of freedom: a fellow

Image by Benjamin Kirschner, Creative Commons Attribution 2.5 License

When the FSFE launched their fellowship back in 2005, I joined to be a fellow almost immediately. I have always been a strong supporter of Free Software and the FSFE is doing a great job in Europe with far less money than the FSF, who is working mainly in the US. This is not an easy task, with so many different countries and legal systems and languages, but they have managed to build up a great network.

I sometimes meet people who ask about what the FSFE is doing precisely and I wonder if they have been living under a rock: preventing software patents, advising the EU in various society issues, building up the Freedom Task Force, offering the Fiduciary License Agreement to developers and much, much more are the daily work of these brave people from the FSFE, which I count among my good friends. So when the fellowship was created, I was glad to join and give some of my money to support their work, knowing I would get a lot back.

Still, I was surprised and honored to be contacted for an interview as a fellow, which you can now read here: The smallest unit of freedom: a fellow.

Friday, April 10. 2009

Nuliajuk Posted by Lydia Pintscher in Nightrose at 10:24

Comments (0)
Trackbacks (0)

Nuliajuk

We have been working hard since the release of Amarok 2.0, building on the foundation we laid with 2.0. Now it is time to to release the first beta version of Amarok 2.1. Please read the release notes and help us find and fix remaining bugs for 2.1.

Breathe., originally uploaded by LunaDiRimmel.

Friday, April 3. 2009

A-Team at OpenExpo 2009, Berne ... Posted by Mark Kretschmann in markey at 15:52

Comments (9)
Trackbacks (0)

A-Team at OpenExpo 2009, Berne (Switzerland)

(Image kindly provided by Nick Schenker)

On April 1st and 2nd (no joke there) a delegation from Amarok visited OpenExpo in Berne (Switzerland), together with our FOSS homies from KDE and Kubuntu. The photo above shows me (left) and Sven Krohlas in action, that is, drinking beer and having cake.

Apart from that we also had the chance to talk to many Amarok users, and demonstrated a preview of the upcoming 2.1 release, on Sven's 20 years old laptop - the thing operates on love and glue strip mostly. (hint: wanna help our project a bit? Donate a new lappy to Sven!)

Many users expressed their sincere happiness about Amarok and about meetings its devs, which of course made us very happy. It's always a rewarding feeling to see that one's work is appreciated. Others offered mostly fair and balanced criticism, which we took seriously and promised to remedy in upcoming releases (2.1 is going to fix a lot of those already).

Other highlights included:

Alexandra Leisse making good on her promise to wear a skirt on the second day.

The Free Beer (a beer with FOSS recipe) which I'm drinking in the above pic.

Catering is always decent at OpenExpo, although they've been a bit skimpy with the yummy Asian stuff this year.

What didn't sit so well with me:

KDE people (Myriam in this case) having to give out GNOME Ubuntu CDs, as Canonical again managed to forget about the Kubuntu CDs. Next time I might use them as frisbees or so. GNOME fails to show up at many expos these days, but through the backdoor (Ubuntu) they spread their software anyway. Not OK in my book.

All in all, the event was decent and we had a lot of fun (as always my patience was stretched thin, but people are used to that by now;) Thanks to everyone who participated, thanks to our users and friends, and especially to Nick, with whom I had a good conversation afterward.

PS:

In 2003, a crack developer squad was sent to prison by a military court for a hack they didn't commit. They promptly escaped from a maximum security stockade to the Amarok Underground HQ. Today, still wanted by the government, they survive as coders of fortune.

If you have a problem, if no-one else can help, and if you can find them, maybe you can hire the AMAROK-TEAM!

« previous page (Page 1 of 3, totaling 43 entries) next page »
Frontpage