MAR
13
2007

The Road to KDE 4: Amarok 2 Development is Underway

This week we'll take a brief look at some of the many features that are making their way into Amarok 2, which is the development branch for Amarok in KDE 4. The features discussed are all in-progress features which have reached varying stages of completion. Read on for information about Amarok's engines (including Phonon), UI changes, changes to the Magnatune music store, OS X support, and more.

A few weeks ago, The Road to KDE 4 featured an article on Phonon. When that article was published, work on Amarok 2 had not yet started, but the Phonon developers were keeping Amarok very much in mind as they designed the Phonon libraries.

You see, in Amarok 1.x, the developers had to maintain separate playback engines for xine, gstreamer, aKode, etc. This was somewhat of a hassle to keep all of these engines up to date, and in some cases, they were very much a moving target, forcing them to focus on only a single engine, xine. And other programs, like Noatun had to re-implement these backends so there was much duplication of efforts. For KDE 4, the Phonon interface is designed so that programs like Amarok don't have to worry so much about the backends anymore and can concentrate on the other parts of the application. According to the Amarok developers, implementing a Phonon backend took all of 90 minutes before it was usable, and a few extra hours before it was fully implemented. When using Phonon, applications can playfiles over network protocols thanks to KIO, so we'll see what happens as the Amarok team explores this feature in more detail.

So Phonon is now working in Amarok 2. The old engines were also ported over, and in particular, the old xine engine is still being actively developed and they haven't decided to drop their old engines. Since Amarok 2 has only been in development for a few weeks, it is too early to decide to drop their existing engines such as xine, which has served Amarok very well in the past.

One of the side effects of using Phonon is that Amarok can access the video playback functions of the underlying engines where they exist, such as in the phonon-xine engine. They have added rudimentary support for video playback in Amarok, but it's designed to complement audio playback, rather than supplant more involved video players like Kaffeine. The idea is that if you have a music video in your collection, and want to use Amarok to play music from that video, then the video stream would be considered as a Visualization for that music. Having video support will in no way hinder your Amarok audio experience in version 2. According to Dan Meltzer, adding initial video support was a whole seven lines of code using Phonon.

Of course, thanks to KDE 4's newfound portability, Amarok is able to run on other platforms, not just Unix/X11. The development version has already made its first appearance on OS X thanks to the work of Benjamin Reed. Porting to Windows as well is underway, although I don't have a screenshot of that progress.

I personally think that having Amarok on these platforms will single-handedly do more for awareness of KDE as a multi-OS development platform than any other application that currently exists for KDE, since the program is head and shoulders above so many other media players out there.

But they wouldn't have a good reason to call it 2.0 unless there were some really big changes happening, and there are.

Amarok is in many ways inspired by XMMS, which in turn bears a lot of resemblance to Winamp. Basically, it's a music player with a multi-column playlist that displays information from tags contained within the media files. Now, these multi-column playlists have not really changed much over the last decade, except that different applications have added interesting ways to sort, filter, and edit tags. Amarok is particularly good at sorting and filtering, and half decent at tag editing (see JuK as an example of a player with an amazing tag editor). But none of these functions really require Amarok to present its playlist in a rigid column format, except for traditional reasons. So as part of the UI reworking for Amarok 2, the playlist is seeing a rebirth of sorts. While it still lists Tracks, Titles, and other tags, it will no longer be constrained by the old fashioned playlist column format.

This requires a picture to properly describe, so here is a mockup showing the concept in action.

You may first wonder "Where is the playlist?" as I and a few of my peers on IRC initially wondered, but if you look closely, the list on the right is actually the playlist, only it's broken free from its old format. So now, when your file is missing some tags, the playlist will simply adjust around those missing tags, smartly displaying what information it does have.

Also featured prominently in this screenshot is the middle pane. This pane is the focus of Amarok 2, as they try to give you more information about your current track, and allowing you to "Rediscover Your Music" as their motto goes. The leftmost column will function much as it used to, except with the "Context" information moved to the centre. Of course, as is KDE tradition, much of this will be configurable.

Here is a shot of Amarok 1.4.5 showing its current layout for comparison as well as a shot of the development branch of Amarok showing off some of the progress they've made in moving user interface elements around. The mockup above is the targeted UI they wish to achieve, but there will be bumps and changes along the way as they find what does and does not work well.

And now another screen the Amarok 2.0 development version, this time on Linux. Keep in mind that Amarok 2 has only been in development for a single month, and work is still ongoing.

One of the most promising of Amarok's features is Magnatune store integration. According to Wikipedia: Magnatune is an independent record label which aims at treating both its musicians and its customers fairly. Users can stream and download music in MP3 format without charge before making a decision whether tobuy or not. Music files sold by Magnatune do not use any form of Digital Rights Management to prevent customers from making copies of music files they have purchased; and actually encourage buyers to share up to three copies with friends.

Amarok debuted with Magnatune support (for both audio streaming and purchase) in version 1.4.4. Since then, the team has received many emails from other stores interested in being added to Amarok as well. But in Amarok 1.4, the developers have been busy polishing up Magnatune support and had no manpower to start bigger tasks. With Amarok 1.4.5, the second version of the Magnatune store was released and developers are really pleased with that version. It works well, and generates a small but growing number of sales for Magnatune.

So it is time to move on. Nikolaj Hald Nielsen, the main developer of Magnatune store, is planning to move things up a higher level by providing a service framework for all streaming music sources. This service framework could, and is in part intended to, be used as a starting point for adding other stores, and will provide a large amount of basic functionality with regards to adding previews to the playlist, displaying data about selected items, and similar "read only" functionality. As a prof of concept, a service that can be controlled using scripts have been implemented on top of this framework. Currently there is no intent to make a framework for the more store specific functionality (purchasing, parsing of info from websites), simply because each store has their own unique way of handling these things. Nevertheless, it's a great step forward for unified streamed music support in Amarok, and in fact, the CoolStreams service has been already ported to this new framework (as a rubyscript), and a Shoutcast browser is coming along.

Now, with the Magnatune store well received and with the possibility of using the service framework, it might be time to contact some of these interested music stores again.

Here is a screenshot showing the experimental "Cool Streams" ruby script running on top of the scriptable service:

If you'd like to get involved in the Amarok 2 development process, you will need to set up a KDE 4 development environment. There are instructions for using SVN available at the KDE TechBase website, or use the kdesvn-build program to automate the whole thing. The Amarok developers accept patches, and will hook you up with SVN access if you require it. They also need help from artists, testers, and people to offer user support via the #amarok IRC channel on the freenode network.

Ladies and Gentlemen, Amarok 2 is progressing very rapidly. To quote Mark Kretschmann, Amarok's lead developer: "If development continues at this pace, we'll be done with Amarok 3 by the time KDE 4 is out ;)" Be prepared for something awesome, as you've come to expect from the Amarok team.

To stay up to date with Amarok news, check out the Amarok Newsletter published by Ljubomir Simin. Special thanks for his contributions to this article. It's my first experience co-authoring, and it went very smoothly. :)

Comments

No it doesn't. It comes nowhere near to providing the functionality common to winamp, itunes and songbird. If you think it is comparable, I can only assume that you have never really used any of those applications.

Amarok is great in many ways, but claiming that a flat single-filter-view is the same as a very flexible multiple-step hierarchical-filter-view is just factually wrong.

Please try one of the mentioned programs out. You should get the idea almost immediately. You get the songs you want into the playlist in a fraction of the time using a fraction of the number of clicks. Not to mention that the overview is far superior to either a flat view or a tree view.


By Smoked at Tue, 2007/03/13 - 5:00am

The drawback of the "multiple-step hierarchical-filter-view" is, that it takes away quite a lot of sceenspace.
For just searching names of artists/albums/songnames, the flatview is quite nice.


By birdy at Tue, 2007/03/13 - 5:00am

Yes, it does take a bit of screenspace if you use the old way of displaying lists. However, the new playlist is an example of an excellent way to remedy this. Using that type of view for the file/album/artists lists in the browser you would not need to use more horizontal space than the current flat view requires to show artist | album | song. If you take a look at Winamp you'll find that it manages to do exactly this. The current interface is very wasteful of horizontal screen real estate, there are heaps of white space around.

Amarok 2 appears poised to fix that! :)


By Smoked at Tue, 2007/03/13 - 5:00am

Expanding on what I said in the first reply:

What puts this type of filter view head and shoulders above either the flat view is that it combines all the practical advantages of both those views into one view. In fact, it actually manages to combine the advantages of any tree arrangement of the filters in question.

To understand what I'm talking about; Consider having the tree view Artist->Album->Song:

To select a song you need three clicks.
To see any song you need two clicks.
To select an album you need two clicks.
To see any album you need one click.
Only artist is directly accessible and visible without clicks.

The flat view has direct access to individual songs, but complete albums and artists are a hassle select.

The multi pane view on the other hand allows selection of any of these with one click, and they are all visible for excellent overview. This is the great advantage to this view.

Having used all these views quite a bit, I consider the multi pane view to be vastly superior to either of the other views. I am not at all surprised that the most used media players in the world use that layout. I am surprised that Amarok does not.


By Smoked at Tue, 2007/03/13 - 5:00am

My collection is both flac (for home listening) and mp3 (for mobile listening). I therefore would like to browse/filter according to file type. Does anyone have any clever ways of dealing with this? Currently, I populate a playlist, then sort according to type, then select and remove from playlist. Not very clever, indeed!


By Alan at Thu, 2007/06/28 - 5:00am

Try "type:flac" or "type:mp3" in the search bar. Works like a charm!
I like amarok more and more every day! Thanks.


By Alan at Thu, 2007/06/28 - 5:00am

I really like the mockup. I've always been annoyed with having a 1440px widescreen and still not being able to see all the information I'd like to (I always have to resize the left pane if I use it), so I really like the way you guys are heading :)

I do hope that the playlist will still be one-click sortable on for example artist or rating, since I didn't see that functionality in the mockup and I kind of use that a lot.

I also agree with Emil Sedgh that tabs in the new middle pane should be avoided at all costs, I hope it'll be possible to present all the information in one view without cluttering the pane up too much.

Again, great work (and great article, too)!


By bsander at Tue, 2007/03/13 - 5:00am

The tabs in the context view are a leftover from 1.x. We do intend to get rid of them :)


By Mark Kretschmann at Tue, 2007/03/13 - 5:00am

The way I envisaged the playlist, you would still be able to sort by any data you like. Prolly a button or right click. We'll find out during implementation I expect.


By mxcl at Tue, 2007/03/13 - 5:00am

great! I think this interface is really the way to go.
First, because the context browser wasn't wide enough (esp for long-line lyrics and wikipedia), so you had to resize it - but then it would be too wide for the collection/playlist/etc browsers. Seperating those is a good thing.
Second, screens are going to be widescreen. And this new design takes advantage of that!!!

And the compact playlist view - lovely...


By superstoned at Tue, 2007/03/13 - 5:00am

but please remember that some of us still have small screens! I assume I'll be able to configure amarok so that it's not too cluttered on my poor tiny laptop - nearly every program I use has to be fullscreen and still feels too small.


By Chani at Tue, 2007/03/13 - 5:00am

Well... How about a horizontal list of the sort order items, which you could then drag around to define in which order you want them to be sorted. To define ascending or descending order, you could simply do as now and click on each item to toggle that.


By Dan Leinir Turt... at Wed, 2007/03/14 - 5:00am

I'd like a little more supprt for podcasts. Now it is still a pain in the ass. You have to scroll down the playlists to the podcasts, refresh the podcasts and download them - then you can hear to them or transfer the files to your mp3-player.

Would it be possible to do it a little more like mypodder from podcastready.com? Every time I connect my MP3-Player the programm loads the most recent - or maybe the three most recent - podcast episodes to the device.


By Torsten at Tue, 2007/03/13 - 5:00am

Well, works for me in amarok 1.4.5... It automatically downloads the podcasts, and put's new podcasts in the que when I connect my audioplayer... Check your settings.


By superstoned at Tue, 2007/03/13 - 5:00am

I'm planning to use the center pane (now called the context view) for detailed podcast info. In 1.4 this was not possible because the browsers where in the same place.
I have used only Amarok for uploading my podcast to my phone for a long time now. I'm no longer convinced that using a GUI program from one single computer is the best way. http://commonideas.blogspot.com/2006/12/podcast-appliance.html might offer a easier way for transferring podcasts to your MP3-player. Guess that behaves a little like mypodder. There is however a possibility to integrate this with Amarok 2.


By Bart Cerneels at Tue, 2007/03/13 - 5:00am

I do like the the look of the proposed interface, however, as shown, there is one obvious showstopper for me. When populating the Playlist from the Collection panel, you will have to drag across the central panel. This is much worse than the present arrangement.


By Stuart Neill at Tue, 2007/03/13 - 5:00am

This is indeed a problem that we're discussing. So far we don't have a good solution. Some ideas:

* Allow dropping on the context view (adds to playlist)
* When starting a drag, extend the playlist view to the left
* Rely on double clicking / context menu

Any ideas are welcome :)


By Mark Kretschmann at Tue, 2007/03/13 - 5:00am

One more for you're list :)

* Move the playlist to the center and put the context view on the side. Really you should be able to reorganise them as you want though.

I really think you shouldn't have the playlist window snapping left and right while you add stuff, but doubleclicking to add to a playlist is fine.


By ben at Tue, 2007/03/13 - 5:00am

Nope, that's a no-go. I'm convinced that the context view needs to be in the center. It's the context information that we want to emphasize in 2.0. The playlist is just a tool.

Also it simply wouldn't look as good.


By Mark Kretschmann at Tue, 2007/03/13 - 5:00am

Indeed. This problem of drag'n'drop was the first thing I thought about when I saw your mockup a few weeks ago. And, like you guys, I have no idea how to solve it, but I agree moving it to the left is NOT the way to go.


By superstoned at Tue, 2007/03/13 - 5:00am

I'm sorry but I think you're getting it wrong... For you, the context is more important, but I'm not sure (no source) it's the case for a majority... Programs are made for end users, arent't they ? For instance, having the context as a toolbox, the way it is now, is perfect, I don't want to get my screen covered by information I don't even read or use most of the time.

So please think about it, the playlist is more than a tool... well it is the central part of a player actually.


By Cypher at Tue, 2007/03/13 - 5:00am

I'm sorry but I think you're getting it wrong... For you, the playlist is more important, but I'm not sure (no source) it's the case for a majority... Programs are made for end users, arent't they ? For instance, having the playlist as a toolbox, the way it is now, is perfect, I don't want to get my screen covered by information I don't even read or use most of the time.

So please think about it, the context is more than a tool... well it is the central part of a player actually.

-----

See a pattern? :) One word: customizability (within limits of course)


By helmudt at Tue, 2007/03/13 - 5:00am

> I'm convinced that the context view needs to be in the center.
> It's the context information that we want to emphasize in 2.0.

Why? Something which Troy's article does not discuss in depth is the rationale for this direction.

From my perspective, the 'contextual information' is an interesting extra to peruse if I need a distraction. The core functionality of Amarok is an audio player, the essential tasks of which I see as:

A) Music selection
B) Playback

(A) means finding music to play and choosing the order in which it is played. (B) means actually playing the audio

> The playlist is just a tool.

I disagree. I think the playlist is an essential part of task (A) relating to selection and playback order of the music.


By Robert Knight at Tue, 2007/03/13 - 5:00am

I never use the context view. It contains information I never need or want to see. The only thing I ever do with the Amarok GUI is move songs between my collection and playlist(s). I'm fine with the layout in the mockup being the default, but if there's no way to configure 2.0 to look and behave like 1.x, I will be very annoyed and go find something else to play my music.


By Noah at Tue, 2007/03/13 - 5:00am

> if there's no way to configure 2.0 to look and behave like 1.x, I will be very annoyed and go find something else to play my music.

lol well do so, go find another player then. Do you think amarok devs are gonna lose some market share or that amarok share holders are gonna sell their stocks all in one?


By patcito at Wed, 2007/03/14 - 5:00am

That was a counterpoint, not a threat. Amarok is a product meant to be used by other people, and so the developers should at least consider the opinions of those people before making radical, non-configurable changes.

Also, why is it that so many people push others to use Free Software, and then rather than offer assistance when somebody encounters something they don't like, tell them to go away? It's incredibly irritating and a great way to drive people away from all this cool software we've got.


By Noah at Mon, 2007/03/19 - 5:00am

I have to agree with the other responses. The context view is an interesting distraction, but it's hardly the central feature of Amarok. After I've found something I want from my collection, Amarok goes in the tray unless I want to find the lyrics. Except for the vertical text on the tabs, I like the current interface quite a lot.

Personally, I'd like to see improved collection management: improve mass-tagging features, and make Amarok a full MusicBrainz client with an interface that doesn't suck (unlike Picard and the original MB Tagger).


By Till Eulenspiegel at Tue, 2007/03/13 - 5:00am

"The context view is an interesting distraction, but it's hardly the central feature of Amarok."

That depends on what you use Amarok for. Since the context info matured with support for last.fm, I use Amarok as much for find and exploring new music as for listening to the music that I already own. The context view is very much the central feature in this usage scenario.

I think the answer is configurability. QT supports dragging and dropping interface elements to different positions. That seems like the perfect solution to this problem to me.It should make both of us happy.


By Smoked at Tue, 2007/03/13 - 5:00am

"Since the context info matured with support for last.fm, I use Amarok as much for find and exploring new music as for listening to the music that I already own."

True; if it were a little better, I think I'd use it to (eg, I want to see tags for the album + artist in the context view, not just the track).

"I think the answer is configurability."

I don't know. Configurability as an excuse for bad defaults is no good. As I said, I kind of like the current system of tabs for the left side. If the context pane is going to become another way of exploring your collection, it should be either/or, not both on the screen at the same time.

Anyway, I'm sure this will get worked out in the end, after there are some betas to comment on.


By Till Eulenspiegel at Tue, 2007/03/13 - 5:00am

> Configurability as an excuse for bad defaults is no good.

And good defaults as an excuse for lack of configurability is even worse. That's one of the big reasons that many of us, myself included, use KDE and not GNOME.


By Noah at Mon, 2007/03/19 - 5:00am

I do not agree.

Having the playlist in the centre is not the "ultimate" solution, but it solves the drag'n'drop problem much better than the other proposals.

To be honest, I really disliked the mockup the first it. It is just too.. different.
But now, I think it looks fairly good, and has lots of potential.

Someone mentioned coverflow, and I think it would be a great addition to the collection browser; not only eye candy, I think it is a very logical way to browse your collection. My thought is to have a horizontal coverflow in the collection:
[]
[_]
[__]
[_]
[]
(Something like that)
You can, of course, add the album with drag'n'drop. A list at the top/bottom shows the 'current' album's information (the album in the middle), like Year, Artist etc., and also the tracks. Of course drag'n'drop would work here too.

OK, there are many problems here, but something like this would be really cool.


By Mogger at Tue, 2007/03/13 - 5:00am

What about having a basket/button in the left pannel allowing you to drag there the collection?


By Daniel Gómez at Tue, 2007/03/13 - 5:00am

This solution has also been discussed. The drawback is that you it would only add to the end of the playlist and you would loose control of where the new content was inserted


By Nikolaj Hald Nielsen at Tue, 2007/03/13 - 5:00am

But that is the case of allowing drop on context or double clicking too.

That could be a shortcut, and if you want more control you drag all over the window.


By Daniel Gómez at Tue, 2007/03/13 - 5:00am

If you really wont be moved in terms of the context not being in the centre then I would say that allowing to drop on the context menu is the best solution.

How I am imagining this works is that when you drag outside the confines of the left panel then a line will extend across the central panel with an arrow pointing the position within the playlist where the tracks will be dropped.


By matt at Tue, 2007/03/13 - 5:00am

I think the last point is a good idea. Kind of allowing the drop on the context panel, but interpreting its position like a drop in the playlist. (Of course a good visualization for the position in the playlist is needed.)

Beside that: I think that a separate Contextpanel is a very good idea and I would love it centered, but it might be a good idea to make the positions of the three views customisable.

And last: Your work is great!


By Sebastian at Tue, 2007/03/13 - 5:00am

That seems like it would make the most sense in terms of dragging from the play list, but one of the things that could be awesome is dragging things like tags out of the context pane that bring associated songs with them. Do they get lines into the playlist as well? I feel like that could get really confusing.


By Ryan at Tue, 2007/03/13 - 5:00am

I was thinking the central pane should be a special drop target, it doesn't look like it should normally receive drops as its just an info pane. Drags from it are a different matter, they should work as normal so the tags thing you mention would be fine. My arrow suggestion was for dropping stuff from left onto right (or right onto left) using the central pane as a special case drop target. If you dragged from the left to inside the boundaries of the right pane the arrow should disappear, its only while dropping on the central pane it should be visible.


By matt at Tue, 2007/03/13 - 5:00am

What about moving the playlist or the content to the top, and leaving a large square-ish area for the content? This would make the drag and drop easier (it wouldn't have to cross the whole content), while leaving the content as the main area.


By Pablo Barros at Tue, 2007/03/13 - 5:00am

How about both collection and playlist on the left, and context on right (occupying center and right columns in current mockup). This takes away space from the collection/playlist, but that can be countered by automatic resizing of the left column. Split the space for collection and playlist 50/50 when mouse not over either, but give majority (80%?) to one when moused over.

Drag to playlist flow:
1. Collection/Playlist are 50/50, user mouses over collection and it automatically resizes to 80/20.
2. User selects songs to drag and drags them downward to playlist. When the mouse crosses from collection to playlist it automatically resizes to 20/80
3. User selects where to place the songs and releases them, populating the playlist. User moves mouse off of playlist and it resizes to 50/50.

Benefits:
-Saves on screen real estate. If I want a lot of information about my collection or playlist, I move my mouse over it. Then when I'm done I recover the space.
-No gap between collection and playlist.
-Leaves "drag to context" free for other actions, plus "drag to context" doesn't intuitively imply "add to playlist" (perhaps drag to context could do something like Pandora and recommend songs similar to the ones you dragged? That would be pretty cool :))
-Automatic resizing = eyecandy opportunity :)

Anyway, that's my 2c. Let me know what you think!


By matt at Tue, 2007/03/13 - 5:00am

Oh, and this is a different Matt from the other reply :-P


By matt at Tue, 2007/03/13 - 5:00am

An idea that popped into my head while reading other replys to this comment:

Extending the playlist was already mentionned, but I imagine that would feel like a rather intrusive change in the GUI while performing the action.

What - with all the talk about transparency and 3D going on - about having a semi transparent copy of the playlist appear right next to where the mouse was positionned? Maybe enlarge it a bit in the process.

I envision this sort of like, as soon as the 'drag' starts, the mouse takes off from the program level, and that additional playlist level appears between 'the cursor' and the background. Like in a movie, where the camera moves away from an object while at the same time adjusting the zoom - and another object comes into view ...

As usual I have no idea whether or not it's possible or even if this makes sense.


By Richard Bollinger at Tue, 2007/03/13 - 5:00am

As you have mentioned possibly extending the use of "double clicking" may I make the suggestion that Amarok2 respects the users' preference with regard to single vs. double clicking as chosen in the KDE mouse configuration. While undoubtedly "double clickers" are in the majority, there is surely a significant number of "single clickers" for whom the instructions on the current Playlist rankle. As far as I can see, Amarok stands alone among the major KDE applications in unnecessarily prescribing this behaviour. I would hope therefore that the developers take the opportunity which Amarok2 presents to make a more integrated desktop for many users.


By Stuart Neill at Wed, 2007/03/14 - 5:00am

I like the mockup and I am happy to see the progress in amarok2 to resamble the ideas of the mockup.

What I disliked the most on "old" (alreday great) amarok: sidebar + tabs and not fitting that great on a widescreen display.

What I liked the most on the mockup: no tabs and sidebar ;-) Besides this, the items of the UI are very sensible grouped in the mockup. You have the "control area" on top that sticks on ones eyes because of the colored background (hope this will find it's way into the code some day). You have your collection to the left, the context info at the center ("show lyrics" and such would be nice to have here as "links" cause we don't want any tabs, right?). The playlist to the right is great as well - it is beautiful, informative and needs much less horizontal space as the "classic" playlist. In general I like the "flat" "htmlish" look of the mockup (well, that might be because it's a mockup). I hope you guys manage to resamble that look with qt4.

What came into my mind when I read the artice: the new mockup ideal is IMHO _much_ better then the experimental context-browser/playlist merge that was introduced in an amarok-1.X-beta (and then delayed). So please don't say amarok devs don't care about there users. This mockup seems to be very well though of.

Keep on the great work!
Sero


By Sero at Tue, 2007/03/13 - 5:00am

Regarding the experimental layout from 1.4-beta: I've come to the conclusion that a top/bottom ordering of main widgets always looks messy and cluttered.

As you can see on the new mockup for Amarok2, there is a natural beauty in ordering the views strictly horizontally: Left, Middle, Right. Also this layout scales great with widescreen displays, which are becoming increasingly common.


By Mark Kretschmann at Tue, 2007/03/13 - 5:00am

I agree this is a good idea to split the GUI in 3 horizontal parts.
The new GUI is really beautiful.

It seems like there are a lot of always-unhappy-users who would prefer the old gui. I think it might be a solution to make the layout a bit customizable (ie possibility to switch the right and the middle part, possibility to hide one of the 3 parts, etc).
I have not tested amarok2 yet, and I don't really know Qt... but I'm under the impression this could be easily feasible.

Keep up the good work, and try to keep the new GUI as simple as it is now ! :)
Don't let conservative users destroy your innovative spirit :)


By shamaz at Tue, 2007/03/13 - 5:00am

I think the mockup for Ammarok 2.0 looks rather smart. Its clear easy to follow. Hopefully each of the panes will be reszable so that the playlist pane can be made wider.

What I dislike about the mockup is the controls and visualisation along the top. Firstly they seem out of reach along thwe top compared to there possition with the 1.x series. Secondly they donot fit in properly in terms of visualr look. The shole background shifting colour looks out of place and rather windows vista to me. If they were to remove the colour blending and have the background the same colour as the rest of the application back ground (in the same way as the current 1.x series does), or even just not bother changing appearence of the controls section (they work perfectly fine at the moment and are visually pleasing) then the mockup would be perfect.

If the controls section were to change to how it currently looks then the mockup would be perfect. I would certaintly use it.


By tuxedup at Tue, 2007/03/13 - 5:00am

The coloured background was me messing around. I doubt it'll end up in the final product. Although I kinda like it still :)


By mxcl at Tue, 2007/03/13 - 5:00am

Maybe instead of the tabs, there should be three folding frames in the middle instead. Then the user can unfold the frame he wants to see.

The play bar on the top seems reasonable. It's good to have nice large controls for the user. Of course these should be customizable though..

Cheers
Ben


By ben at Sun, 2007/03/18 - 5:00am

- Tabbed playlists
- A fullscreen mode
- Multiple collections
- Volume normalization without a need for scripts
- Recording / capturing streaming media to disk
- A better use of covers (maybe similar to Cower Flow)
- More data from last.fm integrated into Amarok

This is what the users want, and this is what should be added to Amarok 2.0.

Nobody asked for a GUI refactoring, but everybody asks for the above features...

So which of those features will make it in Amarok 2.0? That's the really important question here, not the GUI...


By fish at Tue, 2007/03/13 - 5:00am

Pages