Planet Amarok

(image copyright by Wade Olson)


Anyone else noticed the extreme amount of hate & trolling against KDE lately, and especially against KDE 4? I have a special message for you trolls:

You're fucking idiots.


For your consideration:


1) they ignore you

2) they laugh at you

3) they fight you

4) YOU WIN.


(we're at stage 3 now)

So as Nikolaj has been blogging about his cool new features that he has in store for Amarok 2.1, I feel obligated to reply. Can't let him steal all the thunder and PR!

Amarok 2 introduced many new features, and undoubtedly one of the most controversial ones was the context view. All of a sudden this large area was smack dab in the middle of Amarok, sticking its nose where some users didn't think it belonged. Mostly, this was because it was not always as easy or efficient to display data the data that users wanted, or it was clunky and hard to use. As the context view evolved alongside libplasma, some of the constructs that were used became outdated as well. All in all, the CV was not, in my opinion, living up to its potential and was very much one of the weaker spots of Amarok 2.0.

What is to be done? Improve it, of course! Or, in this case, rethink the basic foundation of how the user interacts with the context view. There are two fundamental things that will be changing in the Context View that you will see in Amarok 2.1:

1) The Layout itself

No longer will there be an idea of "containments, or "activities" (in plasma-speak). This idea, while quite nifty, didn't really work out great in practice, making it hard to manage a large number of applets and move them around. The new CV has a toolbar, almost a bit like the task manager applet for your KDE desktop. This will allow the user to visually see all the applets that are in the contextview, and instantly switch to any applet that he/she wishes to see.

Basic screenshot:



Clicking on any of the applets in the toolbar instantly switches that applet to be the top-most applet. The applets after it are laid out directly underneath each consecutive applet. The little wrench icon that is visible switches between "edit mode" and normal mode. This is the edit mode:



Here the user can add new applets in any location, as well as remove applets. The user can also re-arrange the order of applets by dragging and dropping the toolbar representations.

2) The applets

The fragmentation of data among the different applets provides for a lot of flexibility but not a lot of visual coherence. I personally envision a few select "meta-applets", that take up the whole CV at a time, but integrate data from multiple sources and lay it out in a coherent, simple, and space-efficient manner. So, a "web info" meta-applet would have wiki information, last.fm artist bios, lyrics, upcoming events for the artist, and maybe more.

I do want to point out that these are very preliminary ideas that are still being fleshed out, and have not been fully reviewed nor accepted yet by the Amarok team. But with some luck Amarok 2.1 will have an awesomely solid CV that will be able to display much more information in a much saner form.

Back in part 1 I showed a few of the things that will make it into Amarok 2 at some point ( likely for 2.1.0 ).

Today I want to show you another thing that I only recently started working on. Its another somewhat controversial part of Amarok 2, namely the playlist.

Since we first started showing screenshots of where Amarok 2 development was heading, some people have been unhappy with our idea of a new and improved playlist ( and have been extremely vocal about their displeasure ). We have tried reassuring them that the playlist would, in time, come to encompass many of the things from Amarok 2 that they were missing as well as a whole lot more, but it is always hard to communicate such ideas with no screenshots to back them up.

So, since I just today got something running that finally demonstrates some of these ideas, I rush to blog it! Please note that this code is still at a very early state and that there are a few rendering inconsistencies visible that will get sorted out before this ever makes it into trunk.

What this new code does, is basically make the way each item in the playlist is rendered completely configurable. how any rows there should be, what elements ( title, album, artist, score, ... ) should be shown in each row, how much space each element should be given and so on is all fully configurable. (Configurable from a code point of view, the ui for actually configuring it does not exist yet... ). So for instance, configured to mimic the current playlist layout, it might look like this:



That looks a lot like the current playlist, only slightly uglier because of some of the rendering issues I mentioned earlier. Messing a bit with the ( for now, hard coded ) config for the playlist and adding a few elements to some playlist item types we can create something like this:



Here we have added the score to all body item ( tracks in an album group ) and given the title its own line for single track items. Finally, as the grand finale, for people who prefer the Amarok 1 playlist, it is possible to do something like this by making all items have just one line ( and the album header none, thus making it invisible ) and use the same config for body and single track items:



For dramatic effect I have also hidden the context view! Add to this some decent sorting controls, and basically all the functionality from the 1.4.x playlist can be brought back. And yes, some of the items are "jumping a bit", this is one of the rendering issues I mentioned.

I think this playlist will end up being much more configurable and powefull than the 1.4.x one ever was, even if this was not immediately visible in the Amarok 2.0.0 release. But as we have said many times, Amarok 2.0.0 was just the beginning. Now comes the hard part, creating a sane ui for letting the user configure the playlist layout. Luckily, Dan has the concept of how this will work well under control.

This is the first time I've actually gotten around to posting anything on the internet. I've been working on Amarok since we started on the 2.0 adventure, and have stuck my nose in most of Amarok since then. I'm hoping to write a series of posts about some of the cool things in Amarok 2, and some of the cooler things to come. Today I'm going to preview 2.0.1, because as we said earlier, 2.0 was just a beginning, and the evolution is already going full speed.

Amarok's code was in a feature freeze for a while before 2.0 was released. There were all sorts of changes in the code, and all sorts of annoying bugs that needed to be fixed. Fixing bugs is no where near as fun as adding new features, and we needed to stop adding features to let the code settle down. This left Amarok 2 missing some very useful features that Amarok 1.4 had. The good news is, many of these features have returned in 2.0.1

2.0.1 brings back searching in the playlist, as Nikolaj wrote here. Since then, Nikolaj has taken it a step further and added filtering as well as searching, which provides the opportunity to use it much as it was used in 1.4. Seb has also merged his support for queueing, another big feature that was missing in 2.0. In addition, "Stop after Current track" functionality is slowing making it's way back into svn. This is one of those features that is much more useful that it sounds and I've been missing it since it disappeared during 2.0 development.

In addition, media device support is improving. Alejandro has been making all sorts of improvements to ipod and mtp device support. We have plans to add support for generic media devices, and probably others as well. This is a great opportunity for new contributers, as this code is fairly self-contained and requires a device to use (and test) it. If anyone is interested in contributing to Amarok, this would be a great place to start.

I've re-added custom sorting to the collection browser as well. This is something that I don't use all that much, but it's nice to be able to change the sorting order in the collection. In addition, we've fixed somewhere between fifteen and twenty-five bugs already, and will probably fix more before 2.0.1 is officially released in a few weeks.

The other place my focus has been recently is on the windows version of Amarok. It's definitely usable now. I've fixed most of the annoying issues, and I can use it as my primary music player for local and remote music. I'll end this post with a screenshot of Amarok 2.0.1 on windows, and encourage you to try it!

Consider, if you will, the following:

[ 26%] Building CXX object kdeui/CMakeFiles/kdeui.dir/xmlgui/kxmlguiversionhandler.o [ 26%] Building CXX object kdeui/CMakeFiles/kdeui.dir/util/kkeyserver_mac.o [ 26%] Building CXX object kdeui/CMakeFiles/kdeui.dir/windowmanagement/kwindowsystem_mac.o [ 26%] Building CXX object kdeui/CMakeFiles/kdeui.dir/windowmanagement/kwindowinfo_mac.o [ 26%] Building CXX object kdeui/CMakeFiles/kdeui.dir/kwallet_interface.o [ 26%] Building CXX object kdeui/CMakeFiles/kdeui.dir/jobviewserverinterface.o [ 26%] Building CXX object kdeui/CMakeFiles/kdeui.dir/jobviewiface.o Linking CXX shared library ../lib/libkdeui.dylib Undefined symbols: "mac_initialize_dbus()", referenced from: KApplicationPrivate::init(bool) in kapplication.o KUniqueApplication::start(QFlags)in kuniqueapplication.o "mac_fork_and_reexec_self()", referenced from: KUniqueApplication::start(QFlags)in kuniqueapplication.o ld: symbol(s) not found collect2: ld returned 1 exit status make[2]: *** [lib/libkdeui.5.1.0.dylib] Error 1 make[1]: *** [kdeui/CMakeFiles/kdeui.dir/all] Error 2 make: *** [all] Error 2

Above is a linking error I received during the KDE 4.1 betas on OS X.

It is also, as it turns out, the linking error which people are getting when they try to compile kde 4.2 beta 2 on OS X. Back in my younger, more formidable years, I was actually able to not only identify the problem but also propose a solution. Then all of a sudden the problem disappeared and I didn't need to worry about it anymore.
Now, it seems, the bitch is back,
and, we here, on the mac,
would pretty please, like it sack. t.

Per'aps I should skip the poetry. Anyhoo, I reported this to kde-buildsystem and it seems that mail was lost to the ether. Also I hear bugs.kde.org isn't the proper place for this sorta thing. How 'bout one of you just fix it? I've even done half the work for you already, you just have to make it pretty (or somethin').

While we're on the subject of build issues, kdelibs doesn't build with gcc 4.0.1 which has prompted me, in my infinite wisdom, to force building with gcc 4.2. The problem is people on Tiger (OS 10.4) only have 4.0.1. Did I mention that Apple's gcc is patched to accept special non-gnu options. Yah. Soooooooo, in comes this patch to macports (packaging system like BSDs ports i suppose) which allows the masses still in the mire of Tiger to enjoy the KDE 4.1 goodness. The problem is it uses gnu's gcc not apple's. Is it OK to build KDE this way? Are there any apple gcc-isms in the mac specific KDE code? Will Benjamin ever return to save me? These and other questions possibly answered in the comments!

Well trac tickets (bug reports) have been coming in fast and furriously [sic] for the kde4 portfiles in macports. This, is a good thing. It means other people are actually using them. KDE world domination is slowly marching forward and I couldn't be happier about this. Between Nokia internet devices, OS X, Vista, and even Windows 7, KDE everywhere is becoming a reality. Whodathunk?

KDE 4.2 beta2 is also in the wild and if everything works out I''ll have them in -devel portfiles by the end of the day. I think I'll only put up kdelibs, kdepimlibs, kdebase, and kdepim. When I tried compiling these manually after beta1 and they worked. There've been a whole slew of build system changes since then so this might fail miserably. Only one sure way to find out so if you're using the Oh SeX give 'em a try :-) .

I won't test these out myself as I only have so much time in the day but they'll be clearly marked as devel ports w/ nomaintainer so I won't feel bad if they break (or break your system). Speaking of which I need to remember to make them conflict with the 4.1.3 portfiles.

Yes, this is actually edible! My partner Myriam made these special cookies for me, as a gift for our successful Amarok 2.0 release.

Rest assured, I will enjoy the cookies very much. I know they taste delicious



I'd like to wish all of our users, our Amarok squad, and the KDE team a happy holiday season!

First of all, just to get the terminology straight. In this post, I define a filter as something that limits what you actually see in a view, and a search as something that selects items in the view without affecting other elements.

Amarok 1 style playlist filtering.

Since Amarok 2.0.0 was released, one of the frequently mentioned Most Missed Features (MMF) is the Amarok 1.4.x style playlist filtering.

The filtering in Amarok 1.4.x is indeed very powerful, but it also suffers from a number of usability problems and is actually sort of a weirdly placed feature as the collection is where advanced filtering is meant to take place as it will always haver more powerful mechanisms for advanced filtering.

That said, we are very aware that there needs to be a simple way of locating content in large playlists and perhaps even limit the playback of tracks to a subset of what is in the playlist in a non destructive way. Inspired by the progressive searching in apps like Firefox (and indeed many of the KDE 4 applications) we decided to try this out instead. So, hidden away in a small cabin in the very dark woods, far away from streetlights and traffic, I decided to have a go at this.

Amarok 2 style playlist searching.

This morning I committed the initial version of a rather advanced playlist search feature. At its very core, it is just a progressive, as you type, search. This means that as you type, the first track that match the current search term will be selected (and the playlist scrolls to it). Next and previous buttons then allows you to jump around in the tracks matching the search (These really need to get some keyboard shortcuts... Working on that one). The search edit gives immediate feedback on whether there are any matches or not, in the same way that, for instance, the KDE 4 version of Konsole does. By turning the search edit a different color and disabling the next and previous buttons. Now by itself, this is useful, but not super powerful, but this playlist search has a few additional tricks up its sleeve. It is possible to specify which fields should be matched against when typing a query. This is changed by clicking off the fields in a small drop down menu.

Currently it is possible to search any combination of track name, album name, artist name, genre name, composer name or year, and I have a few more ideas for properties to search that i am going to add. It is also possible to "lock" the track progression to only play tracks that matches the current search term. This is toggled using the same small drop down menu. It provides a very convenient way of just playing a particular artist from your all time favorites playlist or any number of similar use cases. Currently this only works when using "standard" or "random track" playback modes however, and I am still pondering whether it actually makes sense for any of the other progressions modes, such as "random album". All the options from this drop down menu are of course stored in the config so the options are persistent across sessions.

We are aware that some people will still miss the old style filtering and that this is not the same thing. We do believe however that a search makes more sense in the playlist than a filter, and that this satisfies many, although not all, of the use cases that the old filter did. Going forward, it might also be possible to add other features to the search, such as selecting all matching tracks, or exporting matches to a new playlist, if there are use cases that support these additions.

One thing I am still pondering is if the filter bar should be visible at all times, making the feature very easily discoverable, or if it should only appear when the search keyboard shortcut is activated....

As mentioned, I committed this code this morning, and baring any major issues turning up, it will be appearing in Amarok 2.0.1 which should be released shortly after new year if all goes well. If you cannot wait that long, it should be appearing in the nightly builds shortly, and failing that, there is always building straight from svn!

How 'bout you? Btw my birthday's on that Sunday.
You coming to Kingston to party right? Riiiiight?
Actually I just intend to go to Cuddy's.
Food's awesome there.

Oh, before I forget...
This trip made possible by the letters e, V, and the number 80.
So thanks ;-)

After our recent release of Amarok 2.0, the first round of reviews from major Internet sites has hit the tubes. It is interesting to note that while we got slightly mixed reviews from our users, the majority of professional reviewers had mostly positive things to say about our baby.

I'm not surprised at all by this outcome - I've been long enough in the software business to know the rules. Again I would like to emphasize that we take every criticism very seriously, as long as it is constructive. And we have a very firm vision of Amarok. Everyone who has met me either on the Net or in person knows that I'm a man of strong visions in which I firmly believe, and that I'm not easily influenced by others to change my views.


Enough of the banter! Let's get to the meat:

Ryan Paul of Ars Technica posted an extremely well written and in-depth review:

Hands-on: Amarok 2 rocks the house

Jeremy LaCroix wrote a balanced and fair review for Linux.com:

Amarok gets a facelift

Kevin Purdy of Lifehacker has written a short but sweet review:

Amarok 2 Released, Windows and Mac Versions in Beta

Austin Modine of The Register reviewed Amarok 2:

Native-Linux music player Amarok gets major overhaul

That's all for now. If you discover any more noteworthy reviews, please post them in the comments section. I might eventually write a follow-up to this article, or simply caress my (planet sized) ego by enjoying the reviews.


Mark Kretschmann

Yesterday, after nearly 2 years of hard work, blood sweat and tear, we finally released Amarok 2.0.0. Reactions so far have been mixed, but this was no worse than we had expected. We are drastically reworking an application that many people are very fond of, and taking it in a very different direction, and for some people this will not be the direction that they had preferred. Also, some of the features that some people depend on in the 1.4.x series are not yet in Amarok 2, and while we have tried being very upfront about this, apparently it is still a big shock to some.

One of the things that has been most controversial so far, is the new look. This has spawned a number of mockups from people who have ideas for way to improve Amarok. Some of these are really good! See these pages for some examples:

http://kde-look.org/content/show.php/A+Media+Player+for+KDE4?content=94472
http://www.kde-look.org/content/show.php/Amarok2+Look+and+Feel?content=93854

From the comments on some of these mockups, its is quite clear however that we face somewhat of an issue of understanding. Comments like

I like your mock =)
It looks 100 times better then current amarok which has usability = 0.

BUT
I can almost guarantee that this will never happen...
Amarok developers are quite "strange" people... It's their way or the highway.
Hey if they were not then amarok 2 would not bad as it does today. =/
and
Amarok already has chosen a look and at best changes now are going to be evolutionary rather than revolutionary.
besides being quite degrading to all the people who have worked very hard on Amarok 2.0.0, to me indicates a profound lack of understanding of the amount of work it takes to actually turn a good mockup into a working look for an application, especially from the artist.

So while we get really nice mockups from time to time that we would love to implement, few of the artists so far has been willing to stick with us to do the actual hard, boring and repetitive work required to actually make it happen. Hence the term "Drive-by Mockups".

So is there a point to this rant? I am not sure. I certainly dont want people to stop making mockups as some of these contain really good ideas, but I would ask people to not attribute to malice or stupidity from our side what is simply caused by few artist having the time and being willing to follow up on their mockups.

We are happy to finally get our baby out of the door. Read the release announcement here: http://amarok.kde.org/en/releases/2.0, check abby’s screenshot tour and help us spread the word on digg, Twitter, your blog and wherever else you hang around :)   This is just the beginning of a long journey. Join us on our way and party with us!

Heya,

it does not happen very often that I blog about advertisements for companies. This one is an exception. I'm feeling good about it, since this company I'm blogging about could actually prove useful to the KDE/FOSS community.

The company I'd like to introduce to you is Linux Lancers. Let me sum up in a nutshell what they offer:

1) For the job seeker: A place to find freelance and permanent FOSS jobs (and free advice).

2) For the company: A place to find competent FOSS programmers.


Freelancing is an attractive job opportunity for many contributors in the Software Libre scene. Myself I have done several freelance jobs, and nowadays I am glad that opportunities are emerging that bring us Free Software experts closer to the companies seeking our knowledge.



Disclaimer:

I do not have any financial interests in this company. I'm posting this purely because I believe that the company offers a service that could be useful for our community, plus I'm friends with the company owner and I enjoy seeing his baby succeed.

Amarok 2.0.0 has been tagged! Short of any really bad bugs showing up the release will be upon us shortly, just as soon as the packagers from the different distros have had a chance to do their thing! This release has been nearly 2 years in the making, and all of us developers have shed blood, sweat and tears trying to make Amarok 2 live up to the vision that has driven us all along. Overall, I am very pleased with the result. Some people will initially miss their favorite feature from 1.4.x but Amarok brings so many new thing to the table, that at least for me personally, it is a far superior player to 1.4.x already.

But this blog post is really not about Amarok 2.0.0 at all. You can be sure that his will be covered in great detail, reviewed, tested, loved, hated, praised, FUD'ed, criticized (both constructively and not so...) and all that in the weeks to come. What I will try to do here is give you a small glimpse into the future, the great big world beyond 2.0.0.

You would think that having worked on Amarok 2 for 2 years, we would need a break. But actually, it seems that nearly all developers have big projects that they are ready to start on as soon as the feature freeze is lifted, or are already happily hacking along on new stuff in Git branches. I currently have 3 such branches containing post 2.0.0 features in different states of completion, and in this blog I will show some of the stuff I am working on in one of them. Remember that all this stuff is fresh raw and untested from my own git branch and may change in any number of ways before it ever gets near a release

Amarok Urls

The idea behind Amarok urls is to give amarok a concise way of referring to different "views" within the application and allow these views to be easily passed around, shared and stored. An Amarok url is simply a url with the protocol "amarok" followed by a command and a series of arguments encoded as a url. For instance "amarok://navigate/service/Magnatune.com" is an Amarok url that will cause the Magnatune service to be shown ( if enabled ). In my git branch, the "navigate" command has been fully implemented, and you can navigate in all the browsers. Amarok also installs a protocol handler, so clicking the link above will startup Amarok ( if not already running ), and make it show the Magnatune service. Actually the navigate command supports additional arguments, so a more complex url could be constructed that would not only show the Magnatune.com service, but also set the sorting mode and filter. So If I wanted to direct you to one of my favorite Magnatune.com artist, "Brad Sucks", I could write a url like this: "amarok://navigate/service/Magnatune.com/artist-album/artist:"Brad Sucks"". In this form, these urls are already useful. For instance, they provide a very easy way for context apples to provide "guided searching" in the browsers where clicking on an album cover in the context view actually browses to this album in the browser. Additionally they could be used if you want to blog about a cool new artist in one of the services, as you could simply provide a link similar to the one above, or online services could provide a "browse in Amarok" link for their content. There are many possibilities! But the concept can be taken further by expanding it into

Bookmarks

A bookmark in my git branch is actually exactly the same as an Amarok Url, but the context in which it is used is different. A url is most often something that comes from an external source, whereas a url that is used internally to store a favorite view is what I call a bookmark ( I am very open for suggestions for a better terminology ). So without further ado we have the first screenshot of the evening, the (very much work in progress) "Bookmark Manager" applet:



This applet allows you to grap the url of whatever state the browser is currently in. So browsing somewhere, setting a view mode and entering a filter, and then pressing the "Get Current" button will generate the corresponding url. The manager allows basic operations such as saving, renaming, deleting and of course applying (activating) bookmarks. I have not quite gotten drag and drop organization working, but that will be possible as well. This is also nice if you want to share a cool view with someone, as you don't have to think about how to manually construct the url, but can simply press "Get Current". Oh as i am sure some people will ask why I made this an applet and not a browser, the reason is simply that since these bookmarks actually "work on" the browser, it makes sense to be able to play around with the bookmarks without the manager getting hidden as soon as you activate a bookmark as it navigates somewhere else in the browsers.

Then someone came up with a use for this that I had not considered. A wish list item on our bugzilla asked for a way of bookmarking content for later. The example given was the user finding a cool Magnatune.com album, but not having time to actually purchase it right now. While the bookmark manager can certainly be used for this, the fact that you have to manually type in the query to isolate the album or artist that you are interested in is less than optimal. So today, during a very long train ride, I came up with this:



Now all albums and artist in all collections (using a nice system I actually implemented to allow the last.fm service to add the "Play Similar Artists from Last.fm" action to all Artists in all collections with out hard-coding anything) have an option to bookmark them. This system does not work in all cases for all services yet (mainly because filtering does not work exactly the same way in all services), but for the local collection, Magnatune and Jamendo, it works perfectly already

This will likely make it into Amarok 2.1.0, so even though Amarok 2.0.0 is, in my opinion, already a great player already, development is in no way slowing down, and we have 100's of really cool ideas that we will work on implementing in future versions.

I have other git branches with post 2.0.0 features lying around, so depending on the response to this post, I might blog about those later

Poisonous people. They exist everywhere, sucking the light and good out of things and repurposing them for all sorts of nasty activities. Like the rest of KDE, and the rest of the software world (both free and non-free) in general, the Amarok team has taken its fair share of abuse over the years. Normally I ignore it. However, today I got my KDE 4.0 Release Event talk twisted around in malicious ways and the blame placed right at my own feet. So I'm rising to the bait.

The latest perpetrator of bile and venom is one Antal István Miklós. This blathering idiot Web Developer called me out personally on his Great Blog (yes, that's really what it's called, if you want to see his post), and turned my well-received talk at the KDE 4.0 Release Event into complaint-a-thon.

I'm not going to pick apart all of the technical wrongheadedness he portrays with MySQL/e, Akonadi, and the capabilities therein -- Nikolaj posted a nice response to the blog, and the guy would be very well served to fully read my posting about mysqle (as well as many of the comments). Much of the blog can also easily be decoded as baseless, factless trolling ("amarok1.x is the slowest KDE3 program, if not it's surely in the top 3 slowest KDE3 programs"), and the-developers-don't-agree-with-me-so-they're-wrong syndrome. But I am going to defend my statements at the Release Event.

Let me explain, up front, the format of my Release Event talk. I presented a short introduction to Amarok, for those that did not know it. I then stated some drawbacks we found with the KDE3 platform. With these drawbacks, plus a desire to go cross-platform like many other media players (VNC, Banshee, iTunes, etc.), we had considered the possibility of switching to a Qt-only architecture. But then, KDE4 comes along, with elegant solutions to our problems -- Phonon, Solid, Plasma, targeting multiple platforms, and more. Boom -- the thoughts of Qt-only go out of our heads, and we commit ourselves fully to KDE4.

Far from a long series of complaints, it's a success story, showing how the benefits the KDE4 platform offer to us solved our problems, and how they could solve yours too. Apparently, however, it simply shows -- from Antal's blog post title, and probably because he hasn't bothered to watch past five minutes in -- how we just don't get KDE4.

This may not be apparent to everyone, but Amarok was an early poster child for adoption of many of the Pillars of KDE. We are the only application, to date, that has embedded Plasma inside of our application (with our developers doing a large amount of work to make that possible). (Update: we are technically the first, outside of the plasma workspace, but there are others playing with that now.) Device detection completely relies on Solid (which is one reason Mac and Windows ports have no device support right now). And we have completely standardized on Phonon for our media engine. We've also had Oxygen team members working on our icons and our interface.

It's hard to imagine ways for us to more fully integrate with KDE4 than what we are doing. We've gone for KDE4 whole-hog, and it's ludicrous to suggest otherwise. Picking out random Pillars that we don't fully integrate with (yet) does not mean that we are not KDE4-oriented. After all, right now we don't have a use for Marble (who knows? that could change) -- but does that mean we don't get KDE4?

it just reminds me of one of the KDE4.0 release event, where a KDE dev complained that how KDE3 sucked, because they couldn't port Amarok to Windows, and KHTML had bad performance

It'd be nice for Antal to realize that there is a difference between complaining, and listing drawbacks of a platform. (This doesn't really fit into how trolls work, of course.) Yes, I said that two of KDE3's drawbacks were that it made it impossible to port Amarok to Windows (and Mac) and that KHTML rendering was found to be slow. No, I did not say that KDE3 sucked.

But there's nothing new here. It's not like Amarok was alone in wanting to port to other platforms. The Release Event had showcases of KDE4 applications running on both Windows and Mac. But Antal has this fixation that Windows and Mac are suddenly all we care about, taking an out-of-context "consider the majority" statement someone (he doesn't say who) made on IRC about some topic (he doesn't say what, only that it's vaguely somehow about performance):

Using mysqle mostly benefits non-KDE4 desktops, because as I said earlier KDE4 will probably have a mysql server anyway, but isn't improving the KDE4 user experiance top release priority anymore? Is amarok on Windows on Mac more important than getting the best out of amarok on KDE4?

[then, later]

What did the people in the IRC channel had to say about this?

.......

My favorite quote from here is: "consider the majority"

It's like saying: "consider the majority, which are Windows and Mac users, and screw the KDE4 users"

I think Antal fails to realize that KDE is not just a desktop. Windows and Mac users that might be using Amarok are going to be using lots of KDE technologies in the process. Regardless of his mistake, there is certainly no evidence that Amarok cares more about Windows and Mac users, or thinks them the majority of our users. Speaking as a developer, I can tell you that the exact opposite is true.

Antal also clearly doesn't realize that Akonadi is not a requirement of KDE to run (even if it's installed), and therefore the best Amarok could do would be to integrate with Akonadi, but not to depend or rely upon it. Maybe he kind of gets it when he says, my emphasis, "KDE4 will probably have a mysql server anyway" -- we can't rely on probably, or maybe. We need to use what works, always.

He even contradicts himself:

He begins with complaining, how slow was rendering amarok's context with KHTML, so it looks like performance matters in amarok, not that anyone forced them to use KHTML for rendering context...

Make up your mind, Antal. You're right that no one forced us to use KHTML for rendering context, although WebKit wasn't available back then, and hooking into Mozilla was a non-starter. But you want us to be integrating with other KDE technologies...right?

One last point:

Jeff Mitchell the developer who spoke at the event that I was referring to, referenced KDE as a family, but where is the love now? The lack of communication between Amarok and the rest of KDE4(Akonandi) doens't seem to back up Amarok as being a family member.

It is not surprising, given how little he understands of Amarok, KDE, and the integration thereof, that he thinks both that there is a lack of communication between Amarok and the rest of KDE4, and that he implies that Akonadi is the entire rest of KDE4.

I've covered a small fraction of the untruths and inaccuracies in his post, but it's enough -- I've made my points. I love KDE, I have not publicly disparaged it, we Amarok developers are fully committed to the platform, and we are not putting the Windows and Mac ports at a higher priority than the *nix base.

Any comments will be read, but I may decide not to post them.

Continue reading "Avast, We Be Getting Slandered, Yar"

Since Wednesday, we've had KDE 4.1.3 in the macports ports system. This means that if you do something like port install amarok or port install ktorrent (yes those two are actually available) they will automagically be installed for you, with all the dependencies taken care of.

Unfortunately there's a catch. Doing exactly what I said above won't work :-) There are certain necessary features available in some ports which aren't turned on by default. Take okular for instance, which is built as a part of kdegraphics4. It needs poppler-qt4, which is dependent on a variant of the poppler port.

dports$ port info poppler poppler 0.10.1, graphics/poppler (Variants: universal, quartz, x11, qt4) http://poppler.freedesktop.org/ Poppler is a PDF rendering library based on the xpdf-3.0 code base. Library Dependencies: cairo, gtk2, openjpeg, poppler-data, XFree86, xrender Platforms: darwin Maintainers: nomaintainer@macports.org

The Variants section is where the magic is. You can see that qt4 is an option and that will need to be set so that poppler-qt4 will be built. Obviously we don't want to build poppler beforehand, we just want to install kdegraphics4 so you'd need to do something like sudo port install kdegraphics4 +qt4 +quartz -x11.

Amarok would need sudo port install amarok +embedded_server to have mysql5-devel install libmysqld.a. And so on, and so forth. If something fails miserably check the portfile with port edit portname; I left comments in some portfiles as to what variants need enabling. Also, there's no need to use sudo when just viewing the portfiles. Between me and you I recommend the following: +no_x11 +dbus -x11 +qt4 +quartz +embedded_server +soprano

P.S. antigraingeometry refuses to build without x11 support so I removed it as a port dependency in kdebase4. If you need/want ksvg then install antigraingeometry before hand.

The KDE macports release has been brought to you by the letters i, g and the number Y. Enjoy.

We are getting closer and closer. It feels a little like Christmas
Enjoy!

Oh and the SeeqPod service is finally back thanks to Nikolaj \o/ Get it from kde-apps.org or download it in Amarok via GHNS.

The new Amarok scripting interface only supports Qt script. But with the help of Qt Bindings, you can ultimate the scripting usage. Here’s a simple example of using .ui files in a script.

From My ScreenShot

A clip from my encoding fixer script, you can grab the full version from amarok/playground/src/script/encoding_fixer/:

Importer.loadQtBinding( “qt.core” );
Importer.loadQtBinding( “qt.gui” );
Importer.loadQtBinding( “qt.uitools” ); //load the qt binding

function readConfiguration()
{
if ( Amarok.Script.readConfig( “simple_Chinese”, “false” ) == “false” )
mainWindow.children()[1].children()[1].checked = false; //uncheck the checkbox
else
mainWindow.children()[1].children()[1].checked = true; //check the checkbox
}

function onConfigure()
{
mainWindow.show();
}

var UIloader = new QUiLoader( this );
var uifile = new QFile ( Amarok.Info.scriptPath() + “/main.ui” );
uifile.open( QIODevice.ReadOnly );
mainWindow = UIloader.load( uifile, this); //load the ui file
uifile.close();

readConfiguration();
mainWindow.children()[0].accepted.connect( saveConfiguration ); //when OK button is clicked
mainWindow.children()[0].rejected.connect( readConfiguration ); //call the function when Cancel button is clicked

Amarok.Window.addSettingsMenu( “configencoding”, “Encoding Fixer Settings…” ); //add the configuration menu
Amarok.Window.SettingsMenu.configencoding.triggered.connect( onConfigure ); //add a signal

Heads up! Amarok 2.0 is about to release.
I will be really happy to see more scripts ready on kde-apps.org. And I am impressed that there are 10+ scripts out there already even before the release of our RC version.

The mp3 tag encoding is always a problem for the non-latin language users. And the problem will remain for Amarok 2.0.0 final. I feel sorry but we have to postpone the fix till the next release. Anyway, I’d like to show you what is our approach now to this issue and what’s the plan for next.

1. There is an encoding detector from mozilla implemented in Amarok. And the detector code is also in KDE 4.2 trunk now. The detector can detect the encoding from a string. Since there’s not much information from the track meta data, the confidence of the result cannot be very high. From my own experience, I got 70%-80% of the correctness from my collection scan.

2. We’ve tried to use the detector on every type of the tracks, and most people complained on that case. So I limited the functionality for MP3 tag id3v1 only. The assumption is, all id3v2 tags were encoded in UTF-8 and all id3v1 tags were encoded in non-UTF-8.

3. So the 70%-80% correctness is for all non-UTF-8 tracks, but the detector some of the time cannot even detect if it is a UTF-8 string. so the correctness can drop to 50% for some cases, which is not acceptable!

Since Amarok is in feature freeze, I’d add functions to solve this issue someday…

Here is the plan:

1. We really do need to find a way to improve the accuracy of the detector. I’ll look into the code to see if there’s a way.

2. Tracks with the same artist or album should be put together to increase the string length

2. System locale should count. It could provide some clue.

3. Filenames should count. You can tell the title of a track from its filename for most of the cases.

4. I am writing a script, which compare the decoded result with the online search engines.

Sometime I just feel the work is not worth it, since there are not many non-latin language users out there. But how can we attract more mid-east and Asian users without fixing the encoding issues, can’t we?

But hell, mp3 tag encoding is not a KDE bug anyway…

Nepomuk actually does work on os x, it just doesn't start automatically. I better file a bug to get this started automatically. Had to run /Applications/KDE4/nepomukservicestub.app/Contents/MacOS/nepomukservicestub nepomukstorage myself. It was also nice enough to segfault after I launched dolphin so I could get my pics. I'd post them but I'm lazy.

The internet is cool. Thanks Daniel.