Planet Amarok

As others on PlanetKDE already wrote we had a really great time in Berlin last week. The KDE/Kubuntu/Amarok booth was well staffed with my favorite gearheads and new KDE people now to be added to the former group It was nice to meet you folks! One of the best things about this year’s Linuxtag: We finally managed to get our booths (KDE, Kubuntu, Amarok, QtSoftware and KDAB) together as close as possible No more running from one side of the exhibition to the other like in previous years \o/

Thursday was probably the busiest day for me. Ingo interviewed me about Amarok for RadioTux. (Excellent job as always, Ingo! ;-)) The recording of it is available at RadioTux. Shortly after that I had to rush off to join Alexandra in giving an introduction to community management in free software projects in our “Community Management 101″ workshop that was well received.
The other days were filled with meetings and lots of talking to visitors and other projects. It is nice to see the shift in attitude towards KDE 4 compared to Linuxtag last year. A lot of people came to our booth to let us know they use and like KDE 4 now. This really rocks! Those who were not happy with KDE 4 yet mostly had very minor problems which we fixed in a few minutes; like showing them how to add applets to their taskbar or what the places bar in Dolphin is capable of. Oh and I was surprised how many people first didn’t believe I was running a stock KDE 4.2.4 on Kubuntu on my 7′ EeePC. So once again: The tiny thing does indeed run KDE 4 Special thanks for that to the Plasma and KWin team. Plasma and KWin on the EeePC are quite an eye catcher at events like Linuxtag.

Kreuzberg surprised a small group of us on Saturday with CSD. Definitely not what I would have expected for that evening but it was awesome! And let me tell you: Marge’s outfit was great but it wasn’t the best one by far. That one goes to someone dressed as Hellboy shouting “KDE! Awesome!” after seeing Frederik’s KDE shirt. This was my second time in Kreuzberg and the second time there was a party on the streets. Rock! (Way less police than on May 1st though ;-))
Sunday and Monday Frank, Cornelius, Thorsten, Danimo, Dominik, Milian and I met at the QtSoftware office to talk about the future of KDE’s wikis. It was quite productive and results will be visible soon.

Thanks go to KDE e.V. and Amarok for funding and of course the Linuxtag team for another great event.

Oh and btw: I of course signed the FLA as well. (I think I got number 10 - nice round number.)

Everyone going to Gran Canaria: Have a nice time and lots of fun and make sure to blog/dent/tweet a lot for those left behind at home. I want to see lots of photos

On LinuxTag this week I gave a workshop about scripting in Amarok 2 and I promised to put the slides online. So here they are. :)

On related news: tomorrow, which is Monday 29th June, I will be giving an IRC tutorial as part of the Kubuntu Tutorials Day on the same subject. My contribution starts at 23:00 UTC, which is 21:00 for all German readers, and takes place on Freenode in #kubuntu-devel.

I'm really looking forward to it, as I never did an IRC tutorial before. See YOU there, especially if you are interested in developing plugins for Amarok 2! :-)

Now the infrastructure for providing bindings exlusively for test scripts in debug builds is in place. This required some CMake magic to set a preprocessor variable DEBUG in debug builds which then can be used in various #ifdefs to make public slots out of public object members, which then can be accessed from scripts. In the beginning the idea was to do this more elegantly, by putting the slot definitions into other preprocessor defines, like AMAROK_DEBUG_EXPORT. This way a lot of #ifdefs could be saved and the code would be much better to read. Sadly the moc preprocessor required to offer the bindings doesn't understand many commands and #define is one of those it lacks. So now you might stumble upon things like: #if defined(DEBUG)   public slots: #else   public: #endif Sorry, I couldn't find a less ugly way currently.
With that working I started adding bindings to Amarok classes to the script engine for test scripts. Playlist::Actions, Playlist::Controller, PlaylistManager and Meta:TrackPtr are there now. The next problem I stumbled upon was that some more classes have to be known to scripts to write reasonable tests. Currently I'm about to provide a prototype for KUrl, which doesn't work yet, but I think I know what went wrong there.

As of this writing I'm sitting in the train to LinuxTag in Berlin, where I'll be until Saturday, but hopefully some code can nevertheless be written. Feel free to visit our booth or one of our talks and workshops.

Heya everyone,

as you might have read: we again take part as a project at LinuxTag this year. You can find our booth, Mike, us, cool Amarok Shirts and recent SVN versions in hall 7.2b, booth 112.

Apart from that we offer the following highlights:

• Workshop: Amarok Scripting: How to enhance your favorite music player. Wednesday, 14:00, room "Kaiserslautern", given by me.
• Workshop: Community Management 101. Thursday, 16:00, room "Kaiserslautern", given by Lydia Pintscher and Alexandra Leisse.
• Talk: Amarok Overview. Friday, 10:00, room "Ulm", given by me.

I just realized that the organizers gave me two (!) hours for the workshop. So if you have creative ideas for good scripts that can basically be implemented in about one hour please let me know. Maybe we might start working on those!

We also have some winners to announce: four people took part in our free entrance ticket drawing for LinuxTag, so three tickets found their way to Poland and two were sent to winners in Germany. Hint: there are still some tickets left, if you need one...

We told you it was coming. Sure, that was a while back, so you probably thought we forgot about it.  Or maybe you thought we were simply playing politics, tossing empty promises to our users.

Well...you were wrong.

It may be a bit later than planned -- we wanted to have it in time for 2.1, but it didn't happen -- but as of revision 984572, there is now support for storing an Amarok database on a MySQL server instead of the embedded MySQL database.  There's no configuration dialog in the GUI yet, but it's pretty simple to set up, as explained below.  All you have to do is add a few things into your amarokrc file and make a valid user on the MySQL server instance of your choice -- you don't even need to create the database yourself.  (In fact, you shouldn't -- you should let Amarok create the database so we can ensure that the character set and collation are set right.)

Here's how to do it.

1. Update to at least r984572 (of course, updating to the latest revision is probably your best bet).


2. Wipe your build dir clean and rebuild.  Not necessarily necessary, but as 47 files were changed in that commit, it's not a bad idea.


3. After install, run kbuildsycoca4 --noincremental, just in case. 


4. On your MySQL server, run a command like: "GRANT ALL ON amarokdb.* TO 'amarokuser'@'localhost' IDENTIFIED BY 'mypassword'; FLUSH PRIVILEGES;"  Be sure to substitute for "amarokdb", "amarokuser", "localhost", and "mypassword" as appropriate.


5. Open up your amarokrc file, usually in ~/.kde4/share/config/amarokrc.  Add a [MySQL] section:
   [MySQL]
   UseServer=true
   Database=amarokdb
   Host=localhost
   Password=mypassword
   User=amarokuser


6. Close the file and start Amarok.  It should create the database and start a scan of your files.  If you want to switch back to the embedded collection, simply set "UseServer" to false.

Pretty easy!  Be sure to let me know if you have problems -- file a bug and assign it to "mitchell" at a domain of "kde" plus a dot plus "org".

A heads-up on something new in Amarok SVN (and coming in 2.2 for those of you not living on the bleeding edge):

We've had various bug reports over the years relating to character sets and collation, causing issues with matching searches for music or mis-sorted items.  Well, hopefully no longer.

When you update to 2.2 (recent SVN users, see the note at the end of this post), your Amarok database and tables will be converted to use the 'utf8' character set and 'utf8_unicode_ci' collation as default for any table or column created from this point on.  Every single text/varchar field will also be converted through a two-step process to use 'utf8' as the character set (the data inside was always UTF-8, but there was a possible mismatch between what the data was and what the database thought it was, if your mysql wasn't built to use 'utf8' by default).  In addition, the character set used when talking to the embedded server (the protocol in the socket) will be 'utf8'.

Fixing this mismatch between what the server might have been using for character set/collation and the data we're putting in there should hopefully ensure that sorting and tags work very well for our users with some files wth non-Latin1 tags (probably just about everybody these days).

 

* Recent SVN users: if your build date is earlier than this post I'd recommend wiping your mysqle directory (not just a full rescan), as the initial commit of the updating code contained a bug that could possibly cause trouble down the line with user playlists...but you bleeding edge users should be expecting database wipes every now and then 

I've blogged about Amarok File Tracking before and there's a lot of information about it on the wiki.  For those that haven't heard about the goodness of embedded file tracking, check out those links.  There are a couple pieces of good news, and one piece of bad news.

The good news: in current SVN (and thus 2.2) the amarok_afttagger executable will also now handle FLAC and various Ogg-contained formats. Another piece of good news - the amarok_afttagger executable is now contained in the amarok-utilities package, and thus can be run on headless machines without X!  And lastly -- AFT now works with user playlists, so you can move your files around (keep in mind the caveats if you're not using embedded AFT tags) and your playlists will always stay current, in addition to statistics and The Playlist.

The bad news? Something is currently a bit broken somewhere deep inside with Observers which means that The Playlist will only update with the correct new URL once (the metadata observers seem to die after that).  This doesn't seem to be AFT specific but rather seems like a bug that AFT is exposing.  Closing Amarok and reopening it will cause the proper new URLs to be in the playlist.  I'm working on trying to fix that.

(Important note: it writes into the FLAC Xiph comment.  This is the only metadata type actually required by the FLAC spec, and thus is the proper place to put it, but a lot of FLAC files incorrectly only have ID3v2 tags, so depending on the tagger you're using you may only see one or the other.)

Last Friday, trunk was opened for features and changes intended for Amarok 2.2. In the scope of a few hours more than 250 commits had been made as people were frantically committing their local git repos.

Today, less than one week later, I though it was worth posting a little update and a video showing how all of this new stuff fits within Amarok. While most of the stuff that is shown in this video has already been blogged about before its kind of interesting to see it all in Amarok at once after having only been able to run them separately for a while.

The features shown in the video are (roughly in order of appearance)

- New browser navigation interface
- Wikipedia applet mkII.
- Videoclip applet showing matches for current track and playing a youtube video.
- Videoclip applet playing a video podcast.
- Dockable interface elements


Direct link

Since so much stuff in trunk has changed in such a short time, there are plenty of small bugs and visual issues present in the video, but there is plenty of time to work on these before even getting close to a 2.2 release. Considering just how many changes have been made, I am surprised that trunk is currently working as well as it does

Also there are many features currently being worked on that are still not in any state to show of.

Apparently if you go through all the trouble of typing that one command: sudo port install amarok-devel, amarok trunk will be thine.
Why don't these things ever work so well for me? Don't I deserve it?
As things seem to be working I'll update normal amarok to 2.1.1. Someone should tell me if it works since for me, it'll probably not work without some haxxxing. You know, because I don't deserve it.

I wonder if it's because I'm getting an android phone...
Do they know?
I'm scared mommy

P.S.
Updated this.

While the Amarok team has been working on _a lot_ of cool new stuff for 2.2 we havn’t forgotten about 2.1. It’s time for 2.1.1, the first (and likely last) maintenance release of the 2.1 series. Enjoy!
We will also be at Linuxtag next week in Berlin with the rest of KDE and the Kubuntu crowd. If you are around say hello. We have a few free tickets left.

The KDE group of portfiles've been updated to 4.2.4. This might fix the massive breakage that occured when the 4.2.0 tarballs disappeared into the InterEther months ago. Or not.

Some other changes are the addition of liblastfm, taglib-extras and qtscriptgenerator. That's right, everything you need to get your bleeding edge fix of amarok. Except amarok itself.

Installing it requires stuff I'm not going to put in a portfile because Saturday's pretty much done and I've already got it working for me. Muahahahahahahahahahahahaahaaaaaaaaaah.

There is a portfile for Amarok (amarok-devel @ rev 981645 which works except for the lastfm plugin not loading.) This will only get you as far as the needed dependencies though as the compilation'll fail.

It'll be fixed whenever someone else tries to fix it or the check for qtscriptgenerator works.
Here's some potential incentive:

Happy compilings!

<public service announcement>

Heya folks

I will open Amarok trunk for 2.2 development in a few hours (not yet!). As people have a lot of awesome stuff to merge that they have been working on, trunk will be (semi-)broken for a few days and might eat your kittens. So if you compile from trunk you might want to wait a few days unless you want to help us stabilize things, which would of course be greatly appreciated.

Let the breakage begin! (in a few hours)
Cheers
Lydia

</public service announcement>

So, another week has passed and here is, late as always, the new status update.

Last week was not as successful as I hoped it to be. First I fixed some bugs after testing the existing framework. Also it is now possible to tell the framework that a test is expected to fail. Having the "successfully failed" tests logged as "FAILED" was ugly as hell. Now the testResult function has an optional fourth parameter to indicate if that's the case. As this will be relatively uncommon in tests it defaults fo false.   void testResult( QString testName, QString expected, QString actualResult, bool expectedToFail = false ); As some people also want to use the test interface for prototyping new features it's not enough to offer Amarok classes as properties of AmarokTest, as then their number is then fixed. The idea is to make them available to scripts dynamically, so they can create new objects at runtime via 'new' on the heap, like other Qt classes, too. Now that has been something that was not as easy as I thought.

I tried it with SmartPointerList and AmarokUrl the way I thought it was supposed to work. Well, after a day I realized the completely wrong approach, as those classes are not based on QObject... *damn*

So now I'm about to understand how to make arbitrary classes available to scripts. I'd be glad for any hint and/or examples. Hopefully this can be done without writing a QObject based wrapper class for each one...

The following pertains to Aaron's blog post. It is in direct response to this sentence That means you'll look and work native on Windows, Mac, KDE and GNOME if you write using Qt. To which I replied via comment.

NO. NO. NO. NO. NO.
I've said it once and I'll say it a thousand more times: Qt does not look native on Mac OS X.
As a matter of fact it currently (4.5) looks like the bastard step-child of 10.3, 4, 5, and something else.

I can't exactly pin-point what something else is but it has to do with wherever those weird gradients in the title bar came from.

So please, stop saying that Qt looks native on a Mac. It doesn't. Furthermore it never will if people keep telling the trolls (Nokianites?) that it does.

Further even if (when?) the Trolls get that sorted, KDE will still be a big bundle of visual fail because of the requirement for Qt3Support. Using the Cocoa APIs, which I surmise is necessary to use replicate the OS X UI, does not work if Qt3Support is compiled in. I say surmise, because currently, whether you compile Qt with cocoa or not, it's the same old horrid visuals on OS X.

The choice then is +cocoa, -qt3support (-kde). Or -cocoa, +qt3support (+kde). Fukitol. I'm going to just make a blog post.

HOWEVER. Everything written in the comment above is based on my use of Qt via KDE 4 on OS X. That, looks a little something like this:

That, by the way, was taken from the Qt Mainwindow demo.
But there's also the MacMainWindow demo:

Clearly, Qt is capable of rendering a native UI on the Mac. So, I was wrong. I have wronged you deeply Mr. Seigo, and for this, I apologize. Seems to be a recurring theme lately.

HOWEVER. I was admonished after this post to stay on topic, so I'll bring us back to cross platform development. To get Chrome looking and feeling native on all desktops would still require custom code specifically for the mac, because otherwise, you might end up with

instead of

I guess the beauty of Qt is that it'll probably take you much less time, once familiar with the necessary bits and bobbles, to do it.

P.S. Here's a more relevant comparison:

For those wondering what's wrong, here's a hint:

Yes, I am nitpicky. :-)

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)

Just 5 months since we released 2.0 and today we can present you Amarok 2.1 “Let There Be Light” with lots of improvements and new features.
Read the release notes, download it and rediscover music!

For videos of some of Amarok 2.1’s features check AmarokStudios. (Thanks to Abby for the videos.)

In a previous blog post I showed an experimental prototype that aimed to do away with the vertical tab bar along the left edge of Amarok. The many replies to this post was about 50/50 for and against this idea. In the post, I mentioned that I wanted to add some kind of "breadcrumb" navigation bar to make navigation easier and also to always show the user where he "is", something that the tabs, admittedly, quite nicely accomplished, at least for the lowest level (which browser is active).

Since I had some time off last week, I decided to see how I could improve the original idea and add the breadcrumb interface. I quickly realized that the big vertical, kickoff style, back button was not very pretty, so as you will see, the latest version does away with that completely. It also turned out that when you have a nice breadcrumb bar, having each "category" show its own name, as all the services have been doing so far, really does not make much sense, so this is something that I could remove as well. Finally, this new interface finally gave me the chance to display some extended info about each category, before selecting it, something I have been planning to do for a long time for the services and which now makes sense for all categories. The info that is currently shown is just a placeholder until we figure out the real text/image for each item, so don't place too much importance on the actual info just yet!

I guess you think that I have been writing enough and you want to see the video already, so here it is:

Video on youtube

(note that this vid is available in HD)

I think that overall this works much better than the initial version I blogged about (even though I already liked that a lot) and I am confident enough that I can work out the final issues, that I am going to commit this to trunk as soon as 2.2 opens up for development.

As promised: a few words about my Google Summer of Code project.

The aim is, in short, to create a framework for unit testing (and also other tests) so that we are able to detect regressions early in the development process. The tests themselves should be written in QtScript to reduce compile time.

Currently I'm working on a private Git branch which already has some nice stuff in it. Similar to the Collection Scanner there now exists another utility application: amaroktest. It offers test scripts some basic APIs for debugging, writing test results to the logfile, etc. Oh, and just yesterday the first testscript has finished successfully:

<testrun> <testscript name="/usr/share/kde4/apps/amarok/tests/AmarokTest.js">   <test>     <name>AmarokTest: Successful test</name>     <status>PASSED</status>     <time>50084659</time>   </test>   <test>     <name>AmarokTest: Failed test</name>     <status>FAILED</status>     <expected>OK</expected>     <result>not OK</result>     <time>0</time>   </test> </teststript> </testrun> After running amaroktest you can find your test logs in ~/.kde4/share/apps/amarok/testresults/ or whereever your Amarok profile directory is located. The "LATEST"-symlink always points to the newest testlog. Oh, and the measured test time for this very first test log btw was completely wrong, as I forgot to start the QTime for the first test. ;-) Also there is not yet a GUI.

The testscript API is currently very simple, but I guess it will grow as we start creating tests for "real" classes.   AmarokTest.startTimer(); tells the framework, that from now on performance measuring should start. You can do initialization stuff before, without influencing the perf numbers. Passing test results to the framework is also really simple:   AmarokTest.testResult( "AmarokTest: Successful test", "OK", "OK" );   AmarokTest.testResult( "AmarokTest: Failed test",     "OK", "not OK" );   AmarokTest.testResult( "AmarokTest: Successful integer test",  1,    1 );   AmarokTest.testResult( "AmarokTest: Failed integer test",     23,   42 );   AmarokTest.testResult( "AmarokTest: Successful FP test", 3.14,   3.14 );   AmarokTest.testResult( "AmarokTest: Failed FP test",     3.14,   2.71 ); The first two lines are the ones that created the log from above.

Currently I'm thinking about that performance measuring: is there a platform independent way to get the CPU time a thread/process used? QTime seems to count real time, so includes time the CPU is working on other threads, too. Also it "only" has a resolution of 1ms on Linux and 15ms on Windows, it seems...

Next I'm gonna make performance measuring really optional for tests and test the behaviour of the framework with several test scripts to be run.