I must admit that I initially really disliked amarok and much preferred the simplicity of Juk, but the amarok devs are slowly winning me over.

I still often prefer Juk for simple music listening, but sometimes, it is nice to be able to view lyrics as you listen to a song. Amarok also seems to impress the windows-using public a great deal, so I guess they must be doing something right.

The listed features do sound incredible. Anybody know when this version of Amarok will be released and whether Suse will include it in 10.1?

hi. I would love to join your conversation about these "new features" but the website is down, t'would be nice if I didn't get "An error occurred while loading http://rokymotion.pwsp.net:
Timeout on server
Connection was to rokymotion.pwsp.net at port 80", ta.

It's a little sad to see that the decision to have their own (non-KDE) iconset by default was not overturned: I find that very hard to believe, particularly because of the popularity of the bug report on it. For those who aren't aware of it, add votes to the bug if you aren't happy with the decision and its implications:

As everyone has said, this totally breaks down one of the things that KDE tries to prize itself in: slick integration by consistency through its applications. It's a shame that the amaroK devs think themselves "powerful" enough to ignore the users' requests, now. Very sad.

amaroK is good because we disregard the vocal minority and do what is best for the product.

Although I agree we shouldn't theme undo/redo. Otherwise most of the themed-buttons don't have a KDE icon, until now we've used icons that look inappropriate if you use an icon set other than crystal.

The hilarious thing is, if markey had never blogged on this, nobody would be moaning about it now, and come the release we'd probably all be praised for making amaroK more usable because now the icons on the interactive widgets make sense.

Every month I'm more and more tempted to do less and less development in the open, and just realise betas to a restricted audience. But this will never happen, don't worry about it. I'm just tempted to suggest it to markey.

/Although I agree we shouldn't theme undo/redo. Otherwise most of the themed-buttons don't have a KDE icon, until now we've used icons that look inappropriate if you use an icon set other than crystal./
If that were the case there'd be no problem with changing them. The play/pause etc. are used eveywhere that plays media.
/The hilarious thing is, if markey had never blogged on this, nobody would be moaning about it now, and come the release we'd probably all be praised for making amaroK more usable because now the icons on the interactive widgets make sense./
Bollocks. I'd be complaining straight away; not only do the new icons not fit in, they look ugly too.
/Every month I'm more and more tempted to do less and less development in the open, and just realise betas to a restricted audience. But this will never happen, don't worry about it. I'm just tempted to suggest it to markey./
What, because being in the open forces you to actually listen to your users?

> > Every month I'm more and more tempted to do less and less development
> > in the open, and just realise betas to a restricted audience.
>
> What, because being in the open forces you to actually listen to your users?

Actually it's comments like that this that make me pretend I dislike open development. Some of you guys are horrible and make unecessary comments designed to be offensive. Reasonable and pleasant debate will be responded to in kind.

People seem to forget that amaroK is an application for KDE, but not a KDE-application. That is; we are not distributed with the core for a reason. We like to be a little different, we _always_ have. I joined the project at version 0.6.0, and did so because amaroK was trying to push boundies, and emphasised form, usability and aesthetics slightly higher than other KDE projects. We like to look pretty, and yes this does mean we deviate from the KDE look slightly.

Also I have to be honest. The play/pause/etc. icons suck in all KDE icon themes I've seen. I prefer the new amaroK ones, and the consistentency of the icon set makes amaroK seem more polished and more professional, which reflects well on KDE as a whole.

I'll reiterate one of my previous points. We fully expect the new icons to be 70% well received. If this is not the case we'll change our policy with respect to the icons. My personal impression is 90% of the people complaining, haven't built an amaroK that uses them, and judgements based on screenshots are rarely convincing.

But may I emphasise again, we will change the policy on icons if everyone hates them. We always listen to our users, even though people like you consistently spread FUD that we don't. We just don't listen to the vocal minority as they are NOT our users. They are just a small percentage of them.

To clarify, the vocal minority are the people who make loud comments on message boards they know we read. Our actual users send us suggestions and pleasant requests on irc and through email, or discuss amaroK innocently on boards they don't think we frequent.

for as far as KDE had no icon for actions in amaroK - of course its cool you created them.

and i also like the new icons

the icons you guys used for actions which already had an icon, on the other hand, DO make KDE less consistent, and i think it shouldn't be on by default, how nice these icons are - they don't look that good with certain styles, color schemes and iconsets users use. the idea behind a global icon theme is simply destroyed. same with the special color scheme amaroK used to have - it was nice, but just didn't fit sometimes.

now i'd rather see a option (maybe even in the first-time wizard) to choose amaroK's own look - whatever, make it more themable. but don't use it by default, not because most users won't like it - but because it won't fit for those that 'stood up' and changed the theme themselves.

**if you took the time to change the look & feel of KDE, you should be rewarded: apps should look the way you choose**

i think THAT should be the reason NOT to put this theme on by default.

inconsistency - hmmm, important, but hey - who wouldn't know how to use amarok just because it looks a bit different...
but those that changed things GLOBALLY, be it shortcuts, toolbar settings, fonts, colors of icons - they won't like this, they might even be upset. some of them will be able to change it but most won't even think that's possible!

i know, if you disable the custom icons, most users won't see them - only the ones where no KDE icon is available. that doesn't feel right. on the other hand, why not try to get the icons which are not in KDE, officially included!

Part of the problem is that "idea behind global icon themes" has major a problem. There is a real cost that must be paid for that level of configurability, and it is paid for by applications like amaroK losing control of its look, resulting in a mismatch of styles.

As far as getting icons into KDE, KDE 4.0 is the next new version of KDE that we will depend on. That won't be for a while. We've been depending on KDE 3.3 for a while now. Its just not a viable solution, amaroK often has a need for additional icons and we can't wait the year until amaroK depends on a newer version of KDE.

Absolute application-specific configurability cannot be used as a justification for having the new icons enabled by *default*. Consistency is vital, particularly in KDE, and it really isn't for no reason. User-experience and familiarity is dramatically altered by it. Needless to say, I think it's a small sacrifice to not allow such application-specific configurability in order to maintain consistency.

I'm sorry to say, but I can't see any justification for why we're only objecting to this because we saw it in beta. That's not true at all.

Also, I really don't think it's a "vocal minority" when there are many prominent KDE hackers *and* experts who disagree with such a move, and needless to say many users who have thought about it.

I don't really think that anyone has argued that the icons themselves aren't aesthetically pleasing: we're quite agreed on that. I think they would, however, look extremely unfitting with some settings, and the fact that they have aesthetic appeal in absolutely *no way* justifies deviating from such a vital KDE principle (which is there for, yes, a reason). KDE is slick because it's so easily themeable; amaroK's decision greatly deviates from such a principle, and it seems to me like they're ignoring the idea on pretty unsubstantiated presuppositions.

I often envy OSX and XP. They can make their apps look great easily because there is bascially one colour theme and icon set; ie. one look to theme to. XP does some great things with subtle blues and oranges. Orange is the compliment to blue, and thus they have effectively two highlight colours, the normal highlight is dark blue, and you see it when you select things. The orange is used as a kind of super-highlight. In the start-menu it is used as a descriptive text colour. Before someone says it, I also dislike the blue theme on XP, it is unpleasant over time, and although distinctive, it feels unprofessional. I just admire the way they have made the most of what they are stuck with.

KDE only has one highlight colour, and because the colour theme is not fixed, we can't just figure out another highlight colour by generating a suitable compliment using the GIMP. Instead we have had to learn some sophisticated colour modification techniques to try and do such things. And it's hard and doesn't always work, but we still do better than many other KDE apps that use fixed colours and assume the list-view, etc. will have a white or near-white background. Eg, Cervisia.

KDE is too flexible. Fact. It impedes our progress to make unique applications that look as good as they do on OSX and XP.

Of course I also know the strength of KDE is that it has consistency, everywhere. But we are not a KDE application, we are an application that uses KDE. So we try to be a little different. We love KDE still, or we'd have built amaroK on GTK, so we try to have the best of both worlds.

Anyway, to the point. Quite simply, we must have some custom icons, and yes you are right, they will not suit all KDE colour-themes and skins. So what do we do? It seems a moot point to remove the play/pause icons as we still have to have 15 custom icons to represent our other exclusive features that don't have appropriate icons in a KDE-icon-set.

I maintain we should use the KDE undo/redo icons though as these are common and standard actions. Play/pause/et al. are less commonly used and known, and also they represent the media-player, changing them gives us identity.

Correct me if i'm wrong but most if not all amarok devs are volunteers creating a wonderful product for your enjoyment. How dare you talk to them like that. Have you no sense of gratitude. What ever your feelings on the issue at hand it is not fair to resort to name-calling.

As far as I can see, amarok's new icon-theme is by far no complete icon-theme. It's just play/pause/stop/... that are replaced. These icons are not common in other KDE applications. So it's no real break of consistency IMHO.

There are quite a few icons (see the icon page on the wiki), and these icons really *are* used in other applications. Even if it was I really don't think it would justify deviating from a standard (which isn't held for no reason).

I don't like these icons, either. I was annoyed ever since amarok started to use the cartoonish player buttons, which really stick out in my otherwise clean (= boring :-) desktop. But I don't complain. I just fixed that on my computer and keep enjoying amaroK that way. Thanks to the great KDE architecture it's possible to exchange about any images/sounds/whatever. KDE always searches all paths in $KDEDIRS, so you can override any global file in your home directory. For the player icons, for example, you just need to add your favorite icons as $KDEHOME/share/apps/amarok/images/{b_next,b_pause,b_play,b_prev.png,b_stop}.png

I've always found Amarok to be a "shining star" amongst Linux apps in general. I am very pleased with the latest version (1.3.8 in my case on Gentoo). The developers have made some great enhancements to what was already a good program.

I was very excited to see support for flash disc based players such as my Samsung. However, it (Amarok) seems to have a conflict with hal and or udev in KDE. When the player is plugged in (USB) KDE auto-mounts it to my desktop. Amarok recognizes that it's there too (wahoo!), but insists that I mount it when I hit the "Connect" button even though it is already mounted and I can browse it in Konqueror just fine. If anyone knows a way around this, I'd be much obliged.

i tried amarok in the beginning and it was ok, i liked the fetched covers and stuff, but i think over time it has gotten a little bloated. there is so much stuff, so many features that you (or at least I ) dont need.
with amarok getting bigger and bigger it is really becoming a memory-monster and losing points on simple things.
it might attract windows users' attention and i think that is good, when kdelibs are ported it could help spread oss to more desktops, but i am not considiring it for personal use any longer.
juk on the other hand i have really learned to love. it has proven to be less memory-hungry than amarok, it supports gstreamer, too, it doesnt have useless stuff like an ipod menu (or tab or how do you call these modern widgets on the left?) - if you dont have an ipod - and it doesnt spend resources calculating what it thinks will be my next favorite song.
ALSO it is possible to create dynamic playlists from folders, which amarok (for some reason) cannot.
i just hope that with the amarok hype going on, developement on juk is not suspended.

Oh yeah, and amaroK actually can make smart playlists based on folders :) (a dynamic playlist in amaroK is a tad different, more akin to iTunes' party mode) The full path name can be used as a condition, so that's possible :)

JuK will continue on into KDE 4. I think one of the significant "identity" issues with JuK at the moment is that at this point is that it's partially defined in terms of its differences to amaroK and in KDE 4 I plan to solidify that a bit more.

The basic plans for the future of JuK are to try to kind of make ease of use the central focus for KDE 4. In concrete terms that means polishing the interface a bit, trying to think more in work flows. Depending on time there are some new features that I'd like to add as well but they're more about functionality than "interface candy". (For those that want that, this is and will be amaroK and that is in fact a good thing.)

My personal reaction to amaroK is always kind of funny. A lot of people really love the bells and whistles, for me there's something of a visual overload; there's always this weird psychological reaction that the closest thing I can compare it to is claustrophobia and I have a desire to close it. (Again, just to be clear -- I don't mean this as criticism of amaroK -- it's surging popularity clearly indicates that for a lot of people its interface is quite comfortable, but JuK will stay around for the folks like me that like things a bit leaner. :-) )

one little thing about juk: what happened to the old renamer? would it be possible to change the new one so that no new folders are created or files moved, only the names of the files are changed. i have a rather complex sorting hierarchy in my collection and dont want things moved around, i just want "artist - audio track1.ogg" to be converted to values from the tag...

I tried the beta version in the Debian experimental repository. It's great to see that playing audio CDs now works. The iPod generalizations are also very nice.

One thing I would have liked is if it had just used the fact that the KIO audiocd slave provides MP3 (and OGG) encoded tracks. This should have made it easy for amaroK to directly copy tacks off of the CD to any external media player.

The external TransKode script thing just feels a bit like a hack... : )

To do so:
- put a audio cd in the drive
- open the tab 'files' in amaroK
- type 'audiocd:/'
- open the mp3 folder and select the files you want to transfer
- right click and select 'add to media device que'
- go to the media device tab
- transfer the files in the que to your mp3 device