Finally, after hacking on it on and off for over 6 months, Magnatune has officially unveiled the 2 new membership options "stream" and "download". So as not to sound like a bad commercial, I will let John tell the story about these services.

What I would like to spend a little time on, even though I have touched on it before, is the cool way in which Amarok 2 already offers full integration for these 2 new memberships.

With a stream membership, all of the preview streams from the Magnatune service become available in high quality ( 160kbs ) ogg with no nagging speaker announcement at the end of each. ( if configured to use oggs, the mp3 files are also nag free but the same quality as the non member version ). This makes all the Magnatune service content almost indistinguishable from local content. Configured with a download membership, not only are all the streams high quality and nag-free, but the "purchase" option turns into "download" and lets you download as many albums as they like for free ( basically just skips the credit card screen and goes straight to the download dialog ). With a download membership, Amarok 2 essentially turns into the world's first music player with an integrated, unlimited, DRM free music download subscription service ( as far as I can tell ).

Another, slightly more obscure way these memberships affects Amarok 2 is that it can automatically convert Magnatune streaming urls from other sources into membership streams ( if configured to use a membership ). So, for instance, a stored playlist of non-membership mp3 streams can automatically be transformed into high quality membership oggs by Amarok. This makes it possible to do a cool Magnatune service front page in Amarok 2 that just links to "normal" mp3 streams and still ensure that the members get to hear the nag free streams.

Ok, so I am excited ( can you tell? ), but I have been working on these memberships for a long time and has taken great care to ensure that Amarok 2 would be ready to use them when they were launched. So now we just need to get Amarok 2.0 out the door...

The Google-AU blog reports that Google is going to be holding another one of it’s brain busting adventures soon. The post is ended with the following text/clue:

Arrrrrrrr you ready? Onward to the first puzzle, matey! And good luck!

aHR0cDovL3RyZWFzdXJlaHVudC5hcHBzcG90LmNvbS8=

Soon :). 1210550400

Warning: links below contain spoilers.

Shouldn’t take long to figure out. The 10 digits of the final number is a dead giveaway that it’s a unix timestamp, and maps to a particular time. That’s soon.

The seemingly random string is a base64 encoding of a particular website.

The Google-AU blog reports that Google is going to be holding another one of it’s brain busting adventures soon. The post is ended with the following text/clue:

Arrrrrrrr you ready? Onward to the first puzzle, matey! And good luck!

aHR0cDovL3RyZWFzdXJlaHVudC5hcHBzcG90LmNvbS8=

Soon . 1210550400

Warning: links below contain spoilers.

Shouldn’t take long to figure out. The 10 digits of the final number is a dead giveaway that it’s a unix timestamp, and maps to a particular time. That’s soon.

The seemingly random string is a base64 encoding of a particular website.

For comments on comments from yesterday's post please read at the very bottom.

Let's get started with the technical details.

j9FwE_4iU7c/SB907WWLnaI/AAAAAAAABWc/ZwQaMKO-6IE/s320/neon.png" alt="" id="BLOGGER_PHOTO_ID_5197001057968561570" border="0" />
I am not at home right now, so I can't use my awesome paper+pencil-drawing(tm) for this explaination so bear with me in case some parts are a bit too complex (I actually created most code while operating on ballmer's peek, so it's as difficult for me to understand it as it might be for you

Anyway, the Neon framework, which is responsbile for the important parts of the nightly build process (I am considering building as not important here ) is written in Ruby (omg!).

http://websvn.kde.org/trunk/extragear/multimedia/amarok/supplementary_scripts/neon

Those of you who had a look at the upcoming Amarok release script will notice quite some similarities, most of them are caused by the fact that I absolutely hate scrolling in files so both source trees consist of some dirs and a couple of files named according to their use (surprise!).

Neon basically consist of 4 components which more or less rely on each other:

• neon.rb/libneon.rb as core component
• fetcher.rb is handling the collection of sources - more on that later
• publisher.rb is basically a wrapper for various ways of source distribution (e.g. tarball upload via FTP)
• distro.rb is a wrapper for distributions
  

neon.rb is responsible for very very very basic tasks, like setting necessary variables/constants, deciding which parts fetcher.rb actually has to fetch and how to publish the tarballs as well as which distribution processes to invoke (well, and cleanup work, but that might eventually get it's own file).

The first real work that is done, is checking which source trees need to be fetched (Qt gets built once a month - Strigi, TagLib, KDELibs and KDEBase are built once a week - and only Amarok is built once a day). Qt and KDELibs are actually just downloaded from the KDE snapshots on ftp.kde.org, the others get fetched directly from SVN (kdebase, or rather kdebaseruntime is a very cut down version which only ships with stuff that is necessary to run Amarok - the Xine Phonon backend for example).

In case all the SVN magic finished without problems the publishers would kick in and pull the newly created tarballs to some source distribution server (ftp/web server).

Then the distributions get their source packages. All distribution realted tasks are within special files located in neon/distros/ - the only working one is Kubuntu right now, but the processes are the same for most package types anyway.

First it pulls a copy of the source trees, and prepares everything as necessary for the package type/distribution, once that is done, it uploads to a remote build server (in case of Kubuntu this is done package by package to prevent complete meltdowns of the repository in case of an issue.

The most important part is that fetcher.rb created an array listing all fetched source trees (including their SVN revision number), so that all distributions can create an appropriate version string (Kubuntu is using DATE+svnREVISON-0amarok1).

There are a couple of guidelines all distribution packages should follow, for example they should require few to none maintenance. Ultimately the only reason one would have to edit the packaging, once everything works properly, is to make it work for new distribution releases.

Again Kubuntu as example: source packages are created according to the soure tarballs provided by fetcher.rb, they get thrown in a build deamon and run threw some automated cmake/kde build scripts and one gets _one resulting binary per source package.

Also, all packages should come with development headers and debugging symbols (I guess it's pretty obvious why that is

To sum that up: the most tricky part is probably to get the packaging right - general information for distributions are on the wiki page.

Everyone who is interessted in contribution, either contact me personally or use the Neon mailing list

------------------
Regarding Comments:

OpenSuse build service
Good thing, but it's really up to the maintainers where they want to build. For Kubuntu it makes most sense to use the Launchpad Personal Package Archive, for openSUSE however we will of course use the OSBS

Ubuntu -> Debian
Not much of a problem, with a bit of tuning they could actually rely on the same debian directories. The only tricky part is the remote build server, I guess using the openSUSE build service is a good idea?

-dev packages
The first public release of Neon had quite some dependencies on -dev packages, they are there because Neon is also meant to help developers join Amaork development. I removed them from the deps stack (strigi, taglib, kdelibs, kdebaseruntime, amarok) they should disappear from qt at some rebuild as well.
For the developers there will be a seperate package for all necessary -dev packages. Should be available soonish.

Missing Icons?
Should be fixed now.

Wrong Colouring!
I can't reproduce the issue, and actually thought it was fixed months ago. If anyone gets hold of information why this appears please leave a mail at the Neon mailing list

How seperate is it really?
Let's say it that way: the possability that Neon will cause issues with any existing KDE/Amarok/Qt configuration is close to not existing at all.
This also includes your collection.db

For comments on comments from yesterday's post please read at the very bottom.

Let's get started with the technical details.

j9FwE_4iU7c/SB907WWLnaI/AAAAAAAABWc/ZwQaMKO-6IE/s320/neon.png" alt="" id="BLOGGER_PHOTO_ID_5197001057968561570" border="0" />
I am not at home right now, so I can't use my awesome paper+pencil-drawing(tm) for this explaination so bear with me in case some parts are a bit too complex (I actually created most code while operating on ballmer's peek, so it's as difficult for me to understand it as it might be for you

Anyway, the Neon framework, which is responsbile for the important parts of the nightly build process (I am considering building as not important here ) is written in Ruby (omg!).

http://websvn.kde.org/trunk/extragear/multimedia/amarok/supplementary_scripts/neon

Those of you who had a look at the upcoming Amarok release script will notice quite some similarities, most of them are caused by the fact that I absolutely hate scrolling in files so both source trees consist of some dirs and a couple of files named according to their use (surprise!).

Neon basically consist of 4 components which more or less rely on each other:

• neon.rb/libneon.rb as core component
• fetcher.rb is handling the collection of sources - more on that later
• publisher.rb is basically a wrapper for various ways of source distribution (e.g. tarball upload via FTP)
• distro.rb is a wrapper for distributions
  

neon.rb is responsible for very very very basic tasks, like setting necessary variables/constants, deciding which parts fetcher.rb actually has to fetch and how to publish the tarballs as well as which distribution processes to invoke (well, and cleanup work, but that might eventually get it's own file).

The first real work that is done, is checking which source trees need to be fetched (Qt gets built once a month - Strigi, TagLib, KDELibs and KDEBase are built once a week - and only Amarok is built once a day). Qt and KDELibs are actually just downloaded from the KDE snapshots on ftp.kde.org, the others get fetched directly from SVN (kdebase, or rather kdebaseruntime is a very cut down version which only ships with stuff that is necessary to run Amarok - the Xine Phonon backend for example).

In case all the SVN magic finished without problems the publishers would kick in and pull the newly created tarballs to some source distribution server (ftp/web server).

Then the distributions get their source packages. All distribution realted tasks are within special files located in neon/distros/ - the only working one is Kubuntu right now, but the processes are the same for most package types anyway.

First it pulls a copy of the source trees, and prepares everything as necessary for the package type/distribution, once that is done, it uploads to a remote build server (in case of Kubuntu this is done package by package to prevent complete meltdowns of the repository in case of an issue.

The most important part is that fetcher.rb created an array listing all fetched source trees (including their SVN revision number), so that all distributions can create an appropriate version string (Kubuntu is using DATE+svnREVISON-0amarok1).

There are a couple of guidelines all distribution packages should follow, for example they should require few to none maintenance. Ultimately the only reason one would have to edit the packaging, once everything works properly, is to make it work for new distribution releases.

Again Kubuntu as example: source packages are created according to the soure tarballs provided by fetcher.rb, they get thrown in a build deamon and run threw some automated cmake/kde build scripts and one gets _one resulting binary per source package.

Also, all packages should come with development headers and debugging symbols (I guess it's pretty obvious why that is

To sum that up: the most tricky part is probably to get the packaging right - general information for distributions are on the wiki page.

Everyone who is interessted in contribution, either contact me personally or use the Neon mailing list

------------------
Regarding Comments:

OpenSuse build service
Good thing, but it's really up to the maintainers where they want to build. For Kubuntu it makes most sense to use the Launchpad Personal Package Archive, for openSUSE however we will of course use the OSBS

Ubuntu -> Debian
Not much of a problem, with a bit of tuning they could actually rely on the same debian directories. The only tricky part is the remote build server, I guess using the openSUSE build service is a good idea?

-dev packages
The first public release of Neon had quite some dependencies on -dev packages, they are there because Neon is also meant to help developers join Amaork development. I removed them from the deps stack (strigi, taglib, kdelibs, kdebaseruntime, amarok) they should disappear from qt at some rebuild as well.
For the developers there will be a seperate package for all necessary -dev packages. Should be available soonish.

Missing Icons?
Should be fixed now.

Wrong Colouring!
I can't reproduce the issue, and actually thought it was fixed months ago. If anyone gets hold of information why this appears please leave a mail at the Neon mailing list

How seperate is it really?
Let's say it that way: the possability that Neon will cause issues with any existing KDE/Amarok/Qt configuration is close to not existing at all.
This also includes your collection.db

A least 5 people ask us every day when Amarok 2 will be ready and when it will be easy to install without compiling it - since yesterday we can tell them: there you go!

Project Neon makes it possible for YOU and me and everyone (kind of, at least

Neon is meant to provide nightly Amarok builds ....
which means that it generates new Amarok packages for various distributions (currently only Kubuntu, openSUSE is in the queue though) ever day so that everyone can install them for whatever reason (testing, checking out the latest development, ...).
... So the main aim of Neon is clearly to provide a way to install the latest Amarok development version.

After installing amarok-nightly you will find an entry in your application menu, I'd like to call that well integrated with the operating system ;-), but the nifty thing about it is, that amarok-nightly will run without problems along a production system, it is stored in a completely unrelated path and all configurations are (or rather should) be stored in it's own directory.

This makes it possible to check out Amarok 2 once a day while running Amarok 1 to get the usual music entertainment.

More information on Neon and how to use it are available on it's wiki page.

Later I will write a more technical post, explaining how it works and how to get other distributions supported.

I’d just like to wish everyone a hearty and happy star wars day.

May the fourth be with you!

Icon credit: everaldo

I’d just like to wish everyone a hearty and happy star wars day.

May the fourth be with you!

Icon credit: everaldo

I never really got to say much about sightseeing in Taiwan after the conference since everything got so busy. After our wonderful post-conference dinner in Danshui, we crashed back the hostel and woke up to a disappointingly drizzly morning. It was a silly idea considering the cloudy skies, but we headed straight to the Taipei 101 - the tallest tower in the world at 101 floors. It is impressively huge. So huge that the tower poked through the clouds and we wouldn’t have been able to have seen anything from the top so we decided to come back later after visiting the Sun-Yat Sen (who forced the Empress out of power) memorial around the corner.

The Taipei 101 is also really cool because it has the fastest elevator in the world, going from top to bottom in an incredible 36 seconds! That’s 1000m per minute! Charlie and his glass elevator really need to upgrade. We also managed to find some Taiwanese fried chicken with mixed vegies for lunch in some back alley behind the world trade center (which we casually strolled through, thongs, singlets and cameras in hand) before discovering a totally awesome suburb of Taipei which only sold computer and camera gear. Seriously, it was streets and streets worth, probably bigger than my university campus (and that’s big, folks!).

The Confucius temple was lots of fun and very colourful, with red and gold decorations and pagoda rooftops adorned with intricate dragons. Seeing as our hostel was close to one of the most famous landmarks, the Chiang Kai Shek memorial, we visited this enormous plaza at the end of the day so that we had a quick getaway back to the hostel for feet resting time. I could not believe the magnitude of this place. It is probably possible to fit over 100 football fields in the space. My camera couldn’t capture the entire space, so here’s a panorama. If you want to get a feel for JUST HOW FREAKING HUGE it is, click on the photo.

Another grand attraction of Taipei is the Shilin night market where you can experience things such as:

- Stinky tofu (it smells worse than gtk+)

- Asian Elvis impersonators with awesome gold pants

- Never-ending arcades stacked full of Dance-Dance-Revolution machines

- Random old Taiwanese men giving random hints on life

- Buying “pets” as close to being Bonsai as you can get without shoving them into a jar

- Awesome fruits, like durian, dragon fruit and rose apple

And then there is the Grand Palace Museum, which true to it’s name is both very grand, palatial and is host to the finest collection of Chinese art in the world.

That’s a lot of links in one post. Here’s another one for good measure:linkety clinkety (completely factual)

I never really got to say much about sightseeing in Taiwan after the conference since everything got so busy. After our wonderful post-conference dinner in Danshui, we crashed back the hostel and woke up to a disappointingly drizzly morning. It was a silly idea considering the cloudy skies, but we headed straight to the Taipei 101 - the tallest tower in the world at 101 floors. It is impressively huge. So huge that the tower poked through the clouds and we wouldn’t have been able to have seen anything from the top so we decided to come back later after visiting the Sun-Yat Sen (who forced the Empress out of power) memorial around the corner.

The Taipei 101 is also really cool because it has the fastest elevator in the world, going from top to bottom in an incredible 36 seconds! That’s 1000m per minute! Charlie and his glass elevator really need to upgrade. We also managed to find some Taiwanese fried chicken with mixed vegies for lunch in some back alley behind the world trade center (which we casually strolled through, thongs, singlets and cameras in hand) before discovering a totally awesome suburb of Taipei which only sold computer and camera gear. Seriously, it was streets and streets worth, probably bigger than my university campus (and that’s big, folks!).

The Confucius temple was lots of fun and very colourful, with red and gold decorations and pagoda rooftops adorned with intricate dragons. Seeing as our hostel was close to one of the most famous landmarks, the Chiang Kai Shek memorial, we visited this enormous plaza at the end of the day so that we had a quick getaway back to the hostel for feet resting time. I could not believe the magnitude of this place. It is probably possible to fit over 100 football fields in the space. My camera couldn’t capture the entire space, so here’s a panorama. If you want to get a feel for JUST HOW FREAKING HUGE it is, click on the photo.

Another grand attraction of Taipei is the Shilin night market where you can experience things such as:
- Stinky tofu (it smells worse than gtk+)
- Asian Elvis impersonators with awesome gold pants
- Never-ending arcades stacked full of Dance-Dance-Revolution machines
- Random old Taiwanese men giving random hints on life
- Buying “pets” as close to being Bonsai as you can get without shoving them into a jar
- Awesome fruits, like durian, dragon fruit and rose apple

And then there is the Grand Palace Museum, which true to it’s name is both very grand, palatial and is host to the finest collection of Chinese art in the world.

That’s a lot of links in one post. Here’s another one for good measure:linkety clinkety (completely factual)

...people who scrobble podcats & radio streams. A podcast != music. Last.fm is the social music revolution, not the social data-garbage revolution. Podcasts belong in a separate database. Lost podcast #121 is not similar to Britney Spears. It's not similar to any artist. Period.



...searching for an artist on google.com and the first twenty results being the same Last.fm page... just in twenty different languages.



...Orange sending me a text-message, welcoming me when I'm abroad. Every fucking 30 minutes. I get it. I'm in Germany currently. Yes, thanks, shut up Orange.



...missing a flight because of bad weather and a now-one-lane motorway.



...having GTA IV waiting for you back home, but not being able to play it because of... well... missing a flight because of now-one-lane motorways?!

In the beginning, the benevolent Ceiling Cat saw that Amarok 2 required tagging abilities, and He saw that it was sorely lacking in both quality and scope. And lo! a solution was presented, in the form of our very own Summer of KDE student Teo, who will be joining the Amarok squad and create the tagging solutions for Amarok 2!


My name is Teo Mrnjavac and I study computer science at the University of Trieste, Italy. My initial proposal was to implement mass tagging in Amarok 2, but givent the current state of things I will have to do a bit of porting to implement basic tagging support as well. While keeping as much as possible of Amarok's existing interface intact, the goal is to implement an unobtrusive and simple, yet powerful interface with the underlying algorithms to mass process the tags and file names consistently on top of the collection browser and to download track information from a remote database.

The key to simplifying the usually clunky rename-from-tags or extract-tags-from-filenames functionality would be a visual layout bar with movable items representing the elements of the filename's syntax. Ultimately, every user, regardless of his tech savvy, should be able to have a consistently and cleanly tagged collection with only a few clicks.

Greetings

Teo

In short, Teo: Welcome!

This is something as rare as a non-technical blog post from me, but I though this was worth posting!

yesterday Magnatune and Amarok decided that it was time Amarok received its first payout of the money earned as commission by selling Magnatune albums through Amarok. This came out to $1155.70 which is 10% of the $11,557 (!!) in sales that Amarok has generated so far. That is actually really good I think! This money will be used to cover hosting and conference costs of the Amarok project and thus will help further improve Amarok.

Besides giving Amarok a 10% commission, Magnatune also employs me, and allow me to spend about half my time Hacking on Amarok, so they truly are a very big supporters of Amarok, and we are delighted to be working with someone who really "gets" free software and free culture.

With the greatly improved Magnatune integration in the upcomming Amarok 2, and the eventual release of Amarok 2 on Windows and Mac, it will be really interesting to see how far we can take this in the future. For now, I hope that the Amarok users will continue to buy music through Amarok, as it is a great way of supporting Amarok development, at the same time as supporting independent artists, who get a full 50% of the purchase price.

John Buckman ( the founder of Magnatune) blogged about this here

Didn’t get a chance to blog about day 2 of the OTST2008 meeting yesterday since everything has been so hectic. Day 2 was similar in order to Saturday, hearing lots of excellent talks about open hardware and software. I found the talks on Freifunk.net and Open Street Map particularly exciting and look forward to seeing how the future plays out.

Later in the afternoon Pradeepto spoke about the kde-edu project, and Ian and I spoke about Amarok 2. It was a little unfortunate that the number of attendees waned towards the end of the day but I still think the event was more than fantastic. Ellis and the folk from Asus treated us all to a wonderful Taiwanese dinner by the seafront in the waterfront town of Danshui. It was great fun :). Here’s most of the team in a group photo:

Summing up, I had a great time. The summit was definitely a great endeavour and hopefully has brought on the right change and the first step to have free software and hardware promoted throughout Taiwan and the Asian world.

Didn’t get a chance to blog about day 2 of the OTST2008 meeting yesterday since everything has been so hectic. Day 2 was similar in order to Saturday, hearing lots of excellent talks about open hardware and software. I found the talks on Freifunk.net and Open Street Map particularly exciting and look forward to seeing how the future plays out.

Later in the afternoon Pradeepto spoke about the kde-edu project, and Ian and I spoke about Amarok 2. It was a little unfortunate that the number of attendees waned towards the end of the day but I still think the event was more than fantastic. Ellis and the folk from Asus treated us all to a wonderful Taiwanese dinner by the seafront in the waterfront town of Danshui. It was great fun . Here’s most of the team in a group photo:

Summing up, I had a great time. The summit was definitely a great endeavour and hopefully has brought on the right change and the first step to have free software and hardware promoted throughout Taiwan and the Asian world.

Introducing Alejandro Wainzinger (xevix on IRC), who is going to be working on media device support in Amarok for SoC 2008:


My name is Alejandro Wainzinger, and I'm going for a Computer Science B.S. at the University of California Santa Cruz, USA. This summer, I'll be bringing back media device support to Amarok for Apple iPods, MTP and generic devices, and making them fly. I chose this project because I own an iPod, and got frustrated with the speed of loading an iPod with a large database, sync'ing of songs/playlists and album art, unlogged crashes after trying to put a 10,000 song queue onto the iPod, and slightly unreliable iPod model detection. That said, I loved having iPod capability in Amarok, and I couldn't see Amarok 2 without media device support.


Alejandro is going to work on getting normal functionality for all three types of devices, and then really taking the iPod plugin to town.

Rumor has it he's then going to attempt making collections out of the devices...
Continue reading "Amarok SoC: Media Devices + Awesome iPod support"

I'd like to welcome Peter Zhou (peterzl on IRC), one of the Amarok SoC students for 2008. I'll let his words introduce him:


Hi my name is Peter Zhou, I am a Mainland China student pursuing bachelor degree in Hong Kong University of Science and Technology.

I am glad that I can now witness the growth of Amarok by involving the core development team. I will redo the scripting interface and rewrite some GUI functions in order to enable the external access to the whole Amarok GUI interface. Then the wolf would have a even more powerful inside.^_^

Good to work with all of you! This is indeed so exciting! Looking forward to seeing you guys in Akademy!

I'd like to welcome Peter Zhou (peterzl on IRC), one of the Amarok SoC students for 2008. I'll let his words introduce him:


Hi my name is Peter Zhou, I am a Mainland China student pursuing bachelor degree in Hong Kong University of Science and Technology.

I am glad that I can now witness the growth of Amarok by involving the core development team. I will redo the scripting interface and rewrite some GUI functions in order to enable the external access to the whole Amarok GUI interface. Then the wolf would have a even more powerful inside.^_^

Good to work with all of you! This is indeed so exciting! Looking forward to seeing you guys in Akademy!

Dear Tristan, I like further developed ideas, mostly, and I also like to develop ideas further.

...I just read such a further developed idea and since I like it a lot, I am goint to develop it further (normal process for me).

Tomorrow Amarok, Linux market leader in the Music Application segment, will announce something revolutionary.
We came to the decision that others know better and therefore we will sync our release schedule to Ubuntu, Linux market leader in the Home User Operating System segment. Our current model of partly time-based and partly feature-based release planing is apparently creating enormous inefficiency in the development of our high-quality software. Mainly because of this we will do 2 releases per year, each 2 days before Ubuntu releases a new version, so that the build servers have enough time to build the packages.
In order to join this with our very fast and feature rich development we will provide at least 25% new or changed code in a time-frame of one year (2 releases), we hope that by setting this minimal growth rate we are able to increase our userbase by 213% per year.
To support these alternations quality assurance will be reduced to a minimum as it can cause scaling issues in combination with this new concept.

This is however only the first step. In a long-term view we aim to breakup the underlying project of Amarok and become a 100% part of the Ubuntu project to share resources and create a strong leader in thew newly created market of Music Home User Appliaction Operating Systems. We also want to prevent our users from wasting half their life with compilation, so we will stop releaseing source tarballs but instead only offer Ubuntu DEB-files.

We will also suggest KDE and all the distributions, we have intensive collaboration with, to start a strong binding to the Ubuntu project as well, and possibly become part of it.

Watch out for the announcement and the moving of our structures from KDE/Amarok ones to Ubuntu/Launchpad.

A nice day wishes your soon-not-to-be-anymore-project-manager.

I'd like to welcome William Soares (Liw- on IRC), one of the Amarok SoC students for 2008. I'll let his words introduce him:

My name is William Viana Soares, I live in Spain although I am from
Brazil and this is my 4th year as a Computer Science Engineering
student. My goal during this summer will be to make Amarok Context
View more usable. I will focus on the the use of libplasma
capabilities to create a nice zooming user interface where all the
context information will lay. I will also be working on Amarok's
Plasma packaging system and in the development of new applets with
contextual information.

I'm really excited that my application was accepted and I'm looking
forward to start coding and see my improvements done for the sake of
Amarok and my own since I'm an Amarok user

We are very glad to have someone working on the Context View again this summer, and i personally can't wait to see all the exciting things that he comes up with.