Amarok Blog

Entries from Tuesday, April 28. 2009

Tuesday, April 28. 2009

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

Comment (1)
Trackbacks (0)

Amarok 2 in Kubuntu Jaunty

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

Improvements and features include but are not limited to:

improved context view

customizable playlist

replaygain support

improved podcasting support

and more

For more please read the 2.1 beta 1 release notes.

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

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

Tuesday, April 28. 2009

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

Comments (17)
Trackbacks (0)

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

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

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

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

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

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

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

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

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

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

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

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

Tuesday, April 28. 2009

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

Comments (0)
Trackbacks (0)

Orbitting the Sun

Forward: This is a repost of the article which I wrote for a recent commit digest report by Danny Allen. Since February, Amarok 2.1 has continued improvement, so don’t take the following content as “exhaustive”.

Amarok 2 marked the first release of the newest generation of Amarok. This marked over two years of very hard work by our entire development team was greeted with great relief by all contributors to the project for a number of important reasons. As developers, we were keen to get our software out the door to users on a larger scale than simply beta quality software. We craved the feedback from the masses to improve Amarok and to get out the feature freeze that seemed to never end. More than that, all developers had great plans for implementing new features and reviving loved functionality that was temporarily removed during the overhaul.

One of the most challenging parts of the transition to Amarok 2 was refactoring the innards of the application to make it more scalable, robust and flexible for future improvements. In many ways, this was one of the biggest technical problems of the 1.4 series — it did not scale well to new features.

Following the release of Amarok 2.0, we received mixed reviews from critics and users alike. Many writers praised the user interface overhaul and infrastructure changes, such as Ryan Paul in his article over at Ars Technica:

“After extensive testing, I’m convinced that Amarok 2 is a major improvement.”

Jeremy LaCroix of linux.com reported a fair review and noted many aspects of Amarok 2.0 that left much improvement to be desired. As a team, we’ve concentrated on many of the concerns that have been raised in reviews and in forum posts by evaluating importance and relative cost of implementation. Examples of requests which we have brought back for the 2.1 release of Amarok include: track queueing, replay gain support, playlist searching and playlist layouts.

We were well aware that with the release of Amarok 2.0, it would be impossible to match the feature set precedent that had been set so high by us in previous releases. To put it simply, we felt that Amarok as a project would have been detrimentally affected by indefinitely waiting to reach feature parity with the 1.4 releases. We were forced to take a stand and simply tell ourselves to wait to implement them. Trying to incorporate the features that are the most useful and important is a difficult task when there are often twelve different responses between five people in a discussion — one man’s garbage is another man’s treasure. That said, we did elect to remove some features from Amarok entirely - mainly for technical reasons (multiple database support for example), some for lack of developer resources (moodbar), and also some for usability reasons (such as tabular playlist design - remember, we’re the experts!).

Initially, the responses to the announcements of dropping features was exactly what we expected — there would be outcry. We expected this for a number of reasons: only the disgruntled speak up, and most readers wouldn’t initially understand how they could adapt to new paradigms. We dealt with this by trying the best we could to deal with the fallout by responding to each individual complaint or worry, but obviously we couldn’t get to all of them (and some were not worth wasting time on). I feel that we’ve managed the community quite well, and that the community has been good to us too by mostly understanding our position and being patient with the developments. Honest communication through blogs of missing features that would return was appreciated by users, and we’ve done our best to bring back the most requested for 2.1.

Many users have decided to stick with Amarok 1.4 for the time being until they see a better set of features implemented. And quite frankly, that’s okay with us. On the otherside, there are users who are keen to try out newer development features but are uncomfortable messing with their system compiling unstable development versions. Neon, our nightly build package service has been praised and exceptionally useful to give users cutting edge builds with no hassle.

Finally, it seems to us that most of our users have noticed the rough edges of the graphics which are being used in the application (specifically the context view). We realise that this does need some work and are trying hard to work with artists develop some great visuals. Also we’ve tried to improve the usability and performance of the context view by providing only a single containment rather than four, and better widgets to use.

If you’re interested in seeing a tour of some of the new (and revisited) features which are coming to Amarok 2.1, take a look at this great overview.

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