With its new 1.2 release, KDE-based media player amaroK becomes the first player to offer integrated support for Audioscrobbler. In close cooperation with the Audioscrobbler team amaroK developers have deployed exciting new ways to use the popular Internet service. Read on to learn about Audioscrobbler and new features in amaroK 1.2.
Audioscrobbler allows users to share music tastes with friends on the Internet, making use of automatically submitted song statistics. amaroK goes a step further than other media players and allows users to receive music recommendations from the site.
In contrast to competing players amaroK does not require a plugin to use this functionality. With the recently released amaroK 1.2 Audioscrobbler support comes built-in and easy to set up. Sunday's release of amaroK has already created buzz in the KDE community.
Also new in amaroK 1.2:
- Support for MySQL databases. Now you can keep your Collection on a remote
computer. - The playlist has seen vast speed improvements.
- 10-band graphic Equalizer.
- Many usability improvements. We have made amaroK more accessible to new users and more comfortable for power-users.
- Automatic song lyrics display. Shows the lyrics to the song you're currently playing.
- Support for your iPod with the all new media-browser.
- On screen display has been revamped, now with optional translucency.
- Theme your ContextBrowser with custom CSS support.
- Support for the latest LibVisual library for stunning visualizations.
- Great new amaroK icon "Blue Wolf", made by KDE artist Da-Flow.
- Better compatibility with GNOME and other non-KDE environments.
- Powerful scripting interface, allowing for easy extension of amaroK.
Comments
Amarok is a great app, and I can't live without it. Its a fine piece of work. But it took me quite some time to get used to it, and altough I know how to use it now, I do think thats wrong. I know, if you are used to how amarok works, its no problem. I'm sure that's why the developers don't see anything wrong with it. And the users don't have a problem anymore. but everyone who sees amarok for the first time is confused, and has no idea what to do. And I think a usabillity report could help.
I know, its not the developers fault - I think its normal. this is how all bad usabillity starts - once you (the developer) gets used to it, you don't notice it. Thats why you guys REALLY need a few outsiders, who know what they are talking about, to check the app. and give some FREE ADVICE. Listen to them, and please - you don't have to do what they say, but at least think about it.
amarok has become better, usabillity-wise. the menu on top is really an improvement, absolutely. so don't think we don't like your app. but it could become better. isn't that what you want? its also what we, the users want. please. don't ignore us, think about usabillity, let some outsiders look at it, and take their comments into considderation.
> amarok has become better, usabillity-wise. the menu on top is really an improvement, absolutely.
Yes, that was something that bugged me, too. That's a very good example where consistency with the rest of the desktop trumps fresh interface design. Every time I wanted to open the menu I first searched automatically in the wrong spot and said "Argh! This is different in amarok."
Thanks for changing that.
yes, you see? the fine guys @ amarok DO listen to users, so I have good faith they will think about the current design (which, mostly, is very good, by the way, and I don't see a way to improve it - but I'm no usabillity expert...).
Just to make sure.... I'm not an amarok developer.
> Aareon Seigo loves amarok.
yes, yes i do. it makes my MacOS X loving friends drool with envy. it makes my music listening experience a joy. it gives me lyrics and other cool toys. it doesn't kill my mail/browsing box at home (which is a PII-400 ... i see no need to harass my devel machine with my email habits, it's already too busy compiling source code =)
HOWEVER ... the toolbar in amaroK is, IMHO, nonsense. i have no problem with it being down on the bottom, but the order and choice of buttons doesn't make much sense. for instance, play is off to the right in the middle of a bunch of other buttons. and what's the most common thing one does when they go to use a media _player_? play. and why undo/redo is on the toolbar, especially when things like enqueue aren't are a bit mysterious to me.
a bug (apparently) in v1.2 causes the sidebar to flip to the context tab when tracks switch automatically. it should only do this when the user switches the track.
clicking on an album cover with no album image in the context view gives you a dialog that says, "close this box and right click!". it probably should have a couple of buttons that allow you to take the most common actions of "select a custom image" or "fetch from amazon.us".
there are other things in there that could use help, like the playlist tab has some inconsistencies.
but ... these are all fairly minor things. polish that will come with future releases. most important is that amaroK seems to have most of the large scale interaction issues down. those are the things that are far hard to change than the default toolbar set up.
luv 'n hugs, aseigo.
hey aaron!
i totally agree, our toolbar settings should be refined. since you're way more experienced in the whole usability area than we are, it'd be cool to get your opinion about the right order of icons down there. a few suggestions you already made, and i guess we will take care of these issues before 1.2.1!
btw, dont know if you noticed the switch in the config dialog: you can completely disable auto-switching to contextbrowser. but again, you still got a valid point: it should only switch there, if the user changed the song.
the third issue is an akward one: to be able to legally fetch covers from amazon, we need to stick to their license. which, i'm afraid, says: clicking on an amazon cover should open the amazon product page. now, you can guess already and you'll prolly agree: we need to stick to the right-click menu for all the covers then (if downloaded from amazon or local). the total inconsistency of click-behaviour would be worse than this little dialog, i assume.
group-hug ;-)
...muesli
As we are on the topic, WHAT do the checkbox and the green LED do in Konqueror? I never found out.
It's for splitted views: The green LED shows the active view. With the checkbox you can "chain" views together (and with "Lock to Current Location" you can fix one of them while having the others following).
If you use multiple views in a split konqueror screen, the checkers are used to link the views with each other (e.g. when changing directory in one view, the linked view will follow the change).
The green led shows which view is currently active
it's retrieving similar artist. if you dont want: disable it in the config dialog.
for all of your funny paranoia-freaks:
1. only the artist name gets transmitted to audioscrobbler.
2. only the first time you play a song of an artist, it retrieves the related artists from audioscrobbler. after that it's cached.
...muesli
I know that this is a contentious issue, but as we move towards KDE 4 the applications issued as part of KDE need to scrutinised.
Amarok is an excellent media player and should become the standard player, with other KDE music players removed.
Kaffeine has demonstrated time and again that it is better than the other movie players and should be the only player provided as part of the standard KDE packages.
How many image viewers, text editors and other applications that do the same task are really needed?
"Amarok is an excellent media player and should become the standard player, with other KDE music players removed."
AFAIK, the Amarok-developers were asked that would they like to be part of "official" KDE. They declined (their release-schedule was too fast IIRC). KDE needs to have an integrated music-player, and since Amarok-guys are not interested, there needs to be another one.
"How many image viewers, text editors and other applications that do the same task are really needed?"
Text-editors should be reduced to one. I know, I know... We have "complex" text-editor (Kate) and "simple" editor (KWrite?). And we have third one (Kedit? I always confuse Kedit and Kwrite) that does BiDi and it will be dropped as soon as Kate can do Bidi. But seriously:
1) I have been hearing about the BiDi-issue for a long time already. How long is it going to take?
2) I don't buy the "complex" editor and "simple" editor argument. Writing text with either of those editors is just as easy/difficult. Sure, Kate has loads of features, but they don't make it really harder to use. And if they do, maybe KDE could implement Kate-profiles like in Konqueror? one profile for full-featured editor, and another for simple editor.
If thoe issues were resolved, number of text-editors would drop from 3 to just one. And maybe we could then drop the "Editors" entry from Kmenu as well? Of course, Kword would be whole different ball of wax.
KWrite basically is a Kate profile. They share the same editing component and KWrite is just a thin wrapper around that.
The problem is that KWrite is still more or less an advanced text editor. KEdit I think is more of the "It's just supposed to edit text, stupid" editor that I think a lot of users are looking for.
Where or is we'll find an answer to this is an open question, but I expect that there will be a fair amount of house cleaning for KDE 4.
> The problem is that KWrite is still more or less an advanced text editor. KEdit I think is more of the "It's just supposed to edit text, stupid" editor that I think a lot of users are looking for.
Yeah, I never understood why people want to remove KEdit and keep KWrite. IMHO KWrite is to advanced for a simple text editor. Please just remove KWrite.
I also never understood why we have a special category for text editors in KMenu. How about moving Kate to "Development" and KEdit to "Utilities". This way we also hide the fact that we have more than one editor. ;-)
> Yeah, I never understood why people want to remove KEdit and keep KWrite. IMHO KWrite is to advanced for a simple text editor. Please just remove KWrite.
I feel the same way. I use Kate all the time. I use KEdit all the time. I never touch KWrite. It's too advanced for a simple text editor and too simple for an advanced text editor.
Best suggestion so far, IMHO.
Just, don't remove kwrite, simply remove the .desktop entry so it disappears from the menu (and people will magically stop complaining). The app/code is good to keep around both as a test for simple KTE editor plugin embedding, and as example code for such an app.
KEdit is a simple text editor. Kate is a programming editor, just a debugger plugin short of an IDE. ;)
(Btw, the amount of virtual ink spilled on this non-issue is amazing. When will people start complaing about KDE shipping with ~10 style plugins? They even take up far more harddrive space than KEdit ever did! Oh, the horror!)
You don't gain anything by removing KWrite. KWrite is just a flimsy shell around the KatePart KPart, while Kate is a more complicated shell around the same component. You can actually remove the KWrite binary and still be able to start it from miniCli (ALT-F2).
Some people actually need the features it has. If you think it puts too much buttons on your toolbar, why don't you just remove them? As soon as this BiDi thing is solved, I'd be glad to see KEdit go. KWrite and Kate I both use regulary.
> You don't gain anything by removing KWrite. KWrite is just a flimsy shell around the KatePart KPart
As if Scott doesn't know this.
I think he is talking more about KMenu than removing it from CVS.
> Some people actually need the features it has.
Then why don't you use Kate.
> I'd be glad to see KEdit go. KWrite and Kate I both use regulary.
For me KEdit starts up much faster than KWrite. And sometimes I just need a stupid plain text editor. That's why I regulary use Kate and KEdit. I don't have any use for KWrite.
>I don't buy the "complex" editor and "simple" editor argument. Writing
> text with either of those editors is just as easy/difficult. Sure, Kate
> has loads of features, but they don't make it really harder to use.
This would get into an interesting discussion with the camp claiming a few extra buttons in a toolbar makes for "horrible usability". ;)
>And if they do, maybe KDE could implement Kate-profiles like in Konqueror?
>one profile for full-featured editor, and another for simple editor.
You mean we should have one meny entry calling "kate --simple" and one "kate --full-featured"? ;) (I hope the irony here isn't lost..)
"This would get into an interesting discussion with the camp claiming a few extra buttons in a toolbar makes for "horrible usability". ;)"
I'm actually in that camp *cough*. My rationale is that we shouldn't have more buttons than needed in the toolbar. Of course, we can argue what is "needed" and what is not. My line of thought is that we should look at the intended core-purpose of the app, and have minimium amount of buttons that allow the user to accomplish that purpose. But I digress.
"You mean we should have one meny entry calling "kate --simple" and one "kate --full-featured"? ;) (I hope the irony here isn't lost..)"
Irony is not lost :). And that's not what I meant. I meant that we could have one app (Kate) with one menu-entry. Inside that app would be different profiles (like we have in Konqueror). One of the features would be full-featured editor (what Kate is today), and another one would be simple-editor.
OTOH, handling of profiles could be handled smoother than they are handled in Konqueror. Right now I have just one button for Konqueror in my Kicker. Once in Konqueror, I load the appropriate profile. And in order to do that, I have to hunt for the relevant settings in the menus. I tried setting a keyboard-shortcut for the profiles (I only really use filemanagement and web-browsing), but I noticed that it can't be done. But, I have to see what 3.4 has in store in this respect. I heard that improvements have been made.
> Right now I have just one button for Konqueror in my Kicker. Once in Konqueror, I load the appropriate profile.
Kicker -> Add to Panel -> Special Button -> Konqueror Profiles
Well I'll be damned! I never knew about that feature! While that does solve my initial problem, maybe profiles could be handled more elegantly (than they are now) inside Konqueror?
Personally I think that really the only apps that should be part of the KDE release schedule are kdebase and kdelibs. Maybe some other apps would make sense as well. Much of the innovative apps (k3b, amaroK, gwenview, digikam, filelight) are in extragear. There really isn't any reason that amaroK can't be 'the' media player and exist outside of the KDE release cycle, its just a matter of communicating this to the distributions.
well, I think there is place for amarok and juk, an advanced and a simple music player.
kaffeine WAS good (until 0.4.2), now they want to be a 'mediaplayer', so they can compete with juk and amarok (?) and play music too. so there is a playlist now (no way to disable it, it seems) and some other stupid features, and the speed is gone. well, I'd say lets just use kmplayer...
about image viewers, that's a bad one :D
texteditors, well, kate and kwrite are the same, I'd say make kwrite a bit more lean, and dump kedit, or give kedit code highlighting and dump kwrite...
> texteditors, well, kate and kwrite are the same, I'd say make kwrite a bit more lean, and dump kedit, or give kedit code highlighting and dump kwrite...
Please no code highlighting in the simple KDE text editor. Just use Kate if you want to have that feature.
The simple text editor should be as fast as possible. IMHO code highlighting would just slow it down.
What computer are you using exactly, and what are you doing to the poor thing that you can see code highlighting in process?
I mean, I used to have highlighted code on text editors on a 486, so on anything capable of running KDE, it should be invisible.
Try to load some 100meg SQL dump just to change one table name... you can have a 4 Ghz CPU but still I hope you don't forget highlighting activated :)))
Please, if you developers go for one complex editor and one simple editor, keep the simple one, well, as simple as possible! (notepad.exe, got the idea? :))
Well, ever tried to load a 100MB SQL dump on notepad.exe? ;-)
LOL! :))
Ok, nice one... but I think you understand what I mean... sometimes one just want to change some character/word/phrase here and there. There surely is place in KDE for an editor wich is just a QUICK editor, with no highlightning to run, no plugins to load, no profile to choose and so on.
Just OPEN -> FIND -> EDIT -> SAVE -> CLOSE (cut/copy/paste as a bonus :)) at the maximum possible speed.
About Kaffeine: I was of your opinion when the first 0.5 serie betas were released, but now with the final 0.5 and a little work of customization I changed my mind. Technologically Kaffeine is perfect, in features is very very good, what is definitely wrong are the default settings. But after removing that absurd "star page", after leaving only a toolbar and after taking it out of the system tray, it returns the lovely player we have seen in the past. Givi it a try! (and I'll try to do some bug-suggestion reporting)
Only problem with kaffeine is that seeking video can't be controled from keyboard...
Yes, from what I read, a lot of people are _very_ disappointed with the changed GUI in Kaffeine 0.5.
> Amarok is an excellent media player and should become the standard player, with other KDE music players removed.
Uh, no. You'll have my JuK when you pry it from my cold, dead fingers.
> Kaffeine has demonstrated time and again that it is better than the other movie players and should be the only player provided as part of the standard KDE packages.
I love Kaffeine 0.4.x. I really do.
However, Kaffeine 0.5 has completely destroyed its usability. If KDE is to include Kaffeine, they should fork it from 0.4.3b and ignore 0.5. Hell, if I were a better coder, I'd fork Kaffeine myself.
> Support for MySQL databases. Now you can keep your Collection on a remote computer
What do you mean? Can I have my mp3/ogg files on another computer? Do they get streamed to my work-computer then, or what?
That's possible, but it's not what the text meant. It meant to read: Keeping your Collection database on a remote computer.
I've got a rather large music collection and have tried most of the KDE audio players. I've found amarok to be the best by quite a margin.
I don't understand how anyone can use Juk when they have a large music archive. Juk is insanely slow when trying to just use the UI.. everytime I try to select a different task the locks up for about 10 seconds while it looks through the music database (or appears to).
amarok seems to have solved this problem quite well... song lookups are extremely quick and accurate.. I really think this should be included in the standard KDE install rather then Juk.
I have never had Juk hang at all on anything, except that it takes a bit to load, but so does Amarok. I don't know what you consider large, but I have 2400 songs so I would expect to see a slowdown if there were one.
I can't imagine what problem you are running into, but it might be specific to you and you need to submit a bug report.
I have a collection of over 3400 songs in juk and I've never noticed any hanging or anything of that nature either.
I still find myself flip-flopping between amarok and juk. Many of the features of amarok are very appealing (tracking which songs I like best and automatic lyric lookup), but I much prefer the juk model of having ones entire collection playing randomly (by song or album). It's nice to be able to push play and hear a random stream of music without having to craft it ahead of time myself. Amarok isn't well set up for this sort of playback (in fact, when I enqueue my entire collection into the playlist, amarok performs noticeably slower than juk on some operations).
I also prefer juk's cover management in some ways. The Amazon covers are of consistent quality, but I have some obscure albums whose covers I was able to find with juk (it just does a google search or something similar, no?), but not with amarok.
Anyhow, they're both great applications that do some things better than the other (for me, at least). I guess my ideal player would be somewhere in the middle, but I don't see that happening. :)
I have an AthlonXP 2200+ system with 768mb of RAM and amaroK is absurdly slow compiling my collection playlist of 4400+ entries, which it has to do every time I need to add stuff. It keeps me from sticking with it every time I try it. JuK, on the other hand, takes a minute or two only if I'm rebuilding the entire list, and is able to handle additions in a quick and timely manner.
I also much prefer JuK's emphasis on collection first, playlist second. It makes things much easier to manage than amaroK's almost XMMS-like single/playlist first, collection second way of doing things.
Come to think of it, I don't think JuK even takes a minute.
I don't have that big of a collection and juk is a bit slow, but still usable until I put something in the search, then it takes in excess of 5 minutes to do anything at all. If I cover it with another window and uncover it, it takes between 5 and 10 minutes to redraw, if I push the play button, greater than 5 minutes before it starts, when the current track ends, it takes another 5 minutes or so before it starts the next one, all the time it is using 100% CPU according to top. I have had this problem across three versions of KDE latest is 3.5.9 and across several distros and machines including a compile from scratch, it has the same symptoms on every machine I have ever tried it on.