(Image copyright by steve)

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

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

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


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


Features that will likely return in Amarok 2

Visualizations

Equalizer

USB mass storage devices support

Crossfading

Stop after this track

Queue feature

Dynamic Collection

Cue file support

Collection statistics

Playlist sorting

Showing new tracks in collection

Labels

ReplayGain

Features which have been dumped. Good riddance!

Old style playlist, "Excel Look"

Support for Amarok 1 scripts

Multiple databases (SQLite and PostGreSQL)

Player Window (this can be implemented as a Plasmoid)

MusicBrainz (we have plans for something better)

Slowness with large collections *grin*

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

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

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



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

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

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

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

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

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

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

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

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


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

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

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






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

Following Danimo, I'm announcing that I (as well as many other Amarokers) will be at FrOSCon too



(Note that my image is cuter than Danimo's)


While I'm at it, I would also like to present my new homepage www.mark-kretschmann.de.



(Note that it's debatable whether I'm cuter than Danimo)

My last blog about Amarok 2 on Windows had been a long while ago, but I'm happy to report that we have some news. Pau Garcia i Quiles committed a number of compile fixes, and it's now possible to build Amarok 2 with MSVC, and to actually run it!

Check this out (click to see full size):




Pau writes:

Yesterday I stayed up until 4:30 AM while trying to fix Amarok to work on Windows, and when I got it to build it was so late I was too tired to test it. So I fired it up this morning and this is the result. I have tested and it plays MP3, WMA, APE and whatever Magnatune streams on. Built with Visual C++ 2008.


I would like to emphasize that this is an ALPHA version. We know it still looks a bit ugly, but this will improve soon.


You can read Pau's original blog here.

My SoC student Peter Zhou has interesting news about his progress with Amarok 2's all-new scripting system. I'm pasting his blog here, as he is not yet aggregated on Planet KDE.

Before that, let me fill you in with the details about our plans for scripting in Amarok 2:

• Amarok scripts are based on QtScript (= JavaScript)


• Scripts are running in-process, as opposed to Amarok 1's way of running them in a separate process


• The new script manager will be able to do version management, and possibly automatic upgrades


• The scripting API will be much richer and it will be possible to extend the Amarok GUI with scripting

What you can expect is something similar to Firefox's extensions. With one big difference: Amarok still aims to provide a rich feature set out of the box. We believe that an application should be usable without forcing the user to do Lego (TM) building


Peter writes:

I’ve been at home for three weeks, was with my family and had a three-weeks-leisure-break.

Finally, I am sitting here to talk about my summer of code project. I am sorry about the first three weeks break, I really do. But I did try to get familiar with the development environment and tried to hack some code. I am going back to campus in Hong Kong in two days, I can thus concentrate on my SoC project.

For a long time, I was trying to understand what is going on there. Trying to think what the other developers think. For the first month I joined the community, I was amazed that Amarok folks are so in love with what they are doing, and have so much passion on it. Different from my past projects, Amarok is a rather large project, different developers had different views on the future way.

For the first time, I am feeling myself being pulled to the bleeding edge. I compiled QT for four times in two different platforms (How many times for kdelibs and kdeRunTime? ). I realized it is sure a though learning process. Playing with the fresh new hot stuffs, I am pretty happy with this.

In the first week, I was busy with my exams, and cleaned up the existing dbus interface.

For the second and third week, I had a slight trip with my girl friend, set up a new Leopard development environment, tested the MPRIS support, and made my first commitment to KDE svn server.

I did some paper work, studied a little with scripts, and I am now quite clear with my goals for the coming busy July.

I made my mind to immigrate everything to qtscript from dbus. I would keep the MPRIS stuffs (PlayerDBusHandler, RootDBusHandler, TracklistDBusHandler) for dbus interface. And the other functions will be scriptable through qtscript. (both ruby and python need additional runtime dependencies, but not qtscript. The simpler the better )

Compare to the current functions, I will add more signals since the signal mechanism are rather easy to be achieved using slots and signals. For example, signals like trackEnd ,trackChange, SeekingTime, configurationChange and etc. would be added.

The second change I will make is the scriptable GUI. You will be able to add buttons, menus, lists using scripts.

Before my visiting to Belgium, I will make a easier use script manager which include upgrade checking, simple dependency checking (to check Amarok version and optional packages for Amarok which will be also needed by scripts).

I am so looking forward to the coming working days and nights. Hopefully, I can work out a brand new scripting interface in one and half months and thus I can start a new script project during my visit to Europe.



Peter's original blog can be found here.