Version: 1.4.0 Beta 3 (using KDE KDE 3.5.2) Installed from: SuSE RPMs OS: Linux After I upgraded to amaroK 1.4b3 I found that you now use custom icons for the player controls. I think those icons look nice when used with KDE's default color scheme. As I don't use the default color scheme, they look out of place there. I think they should be removed in favor of the usual player-control icons provided by the current users' icon theme. Interface consistency is a very important reason to use KDE for me, and I think others as well. With using custom icons for standard tasks in applications you work against this concept. This makes other OSes and desktop environments cluttered and hard to use. I'd like to thank you for developing this otherwise great piece of software.
I found that you can switch back to the system icon theme. Very good decision, but nonetheless I'd suggest you make the system icon theme the default setting and your custom icon theme the optional one. In addition, I'd suggest to move this option to the Appearance-Tab.
As you wrote, there is an option for disabling the theme. So we can close this report. As for changing the default setting, there are no plans to do this, sorry.
I would certainly like you to reconsider this decision, and I urge you to get advice from the KDE Usability Team in order to find out if custom icons as default are a good idea. In usability, there are (amongst others) two rules: 1. The user is always right 2. The user is not always right So, I understand that you may dislike my opposition and apply point 2., because you may also be right with custom icons by default. You may also be wrong and lose your good decision-making ability for artwork that is crafted especially for you. So, let's find out and ask the usability experts.
i'd like to add my votes here. tough i like the new icons, i don't think they should be on by default.
I agree with Jos. I think it's a good thing to be able to change the icons, but I really like amarok becaus of the consistency. I think system icons should be default. Anyway, thank you very much for this wonderfull software.
Wouldn't it be possible to get those custom icons to kdelibs and thus make whole KDE better or is there something why this shouldn't be done? IMHO amaroK shouldn't differ per default a lot from the user's own appearance preferences, but sure it'd be nice to include those anyway...
As there are different opinions on this and already 70 votes in a few hours, I don't think this bug should be closed. Maybe the problem has changed from "I'm missing something" to "My setting isn't the default", but the problem is still there. I ask you to reconsider your decision to close this bug and get into discussion with KDE's usability people. The problem I see with your decision to use custom icons is that it might happen that other applications/projects will follow your decision so we would loose our consistent desktop that seperates us from the others.
No one put in the reasoning for the change in this report yet, so I guess I will. Previously, if someone is using an incomplete icon theme that clashes with amaroK's custom icons (eg. the podcast or collection icons) then there is an inconsistency in style within the app itself. So it was a cost-benefit analysis of having amaroK possibly clash with other KDE apps versus amaroK clashing with itself. Really KDE icon themes in general are probably just bad idea, since very few themes provide 100% of the icons needed. But KDE has them, distros use them, so amaroK supplying all its own icons _by default_ will work around the issue.
Ah well, but following your reasons here, I see one main drawback: - Before you changed it, the defaults were consistent, both system- and application-wide - After you changed it, the defaults are only consistent within the app - If you really care for iconsets different than the default, you may do them a favour by letting them theme your icons by default Ok, that are three points, but they're all different views of one issue. So, will you contact the usability people or do you want to leave them out?
responding to your three points... *Not all distros use crystal as default *Correct *We can neither forbid nor require KDE icon themes to have complete coverage of all our icons (I think you just misunderstand how icon themes work on this point.) The icons have had publicity on the dot, planetkde etc. I don't know if we've talked to "usability people" but discussion has already occured with the wider KDE community.
> I don't know if we've talked to "usability people" but discussion > has already occured with the wider KDE community. In fact, I didn't mean usability wannabies like those anonymous cowards on the dot or me, but rather the official KDE usability team (on http://usability.kde.org/) who are actually researching and evaluating such issues by professional means. As opposed to most users and developers, those people have the necessary background, expertise and methods to give an objective review about planned or already implemented features. kdepim and others have already had successful collaborations with them, maybe amaroK should try the same (and not necessarily restricted to this icon issue).
oh right, i forgot to comment on the other answers: > *Not all distros use crystal as default Most distros do, and the ones changing the defaults shouldn't have problems to change amaroK defaults too. In my opinion, you shouldn't punish the majority for deviations of a minority, and by making a few configurations better, you make many worse than they are now. > *We can neither forbid nor require KDE icon themes to have complete coverage of all our icons (I think you just misunderstand how icon themes work on this point.) As an icon theme maintainer, I think I do understand how icon themes work on this point. It's just when I get a custom icon theme from kde-look.org, do I want a) to get that icon theme applied (though it might be a bit incomplete), or b) to have that icon theme ignored by one app (by default) for sake of application-wide, but not system-wide consistency? And I really think that users that undertake the effort to get and install a custom icon theme want to have that theme applied. If every app ignored it by default, what sense would icon themes make anyways? It is my personal impression that this decision was very much based on short-sighted visual appeals rather than consistency and usability issues, and that the amaroK devs try to justify it with hindsight. I might be wrong though. In any case I want to note that I don't oppose this decision because I'm a HIG zealot or blind aseigo follower, but because I love amaroK and don't want to see it tearing apart from the rest of the desktop, and stimulating other apps to follow this (in my opinion fatal) route.
On Monday 10 April 2006 23:18, Jakob Petsovits wrote: > It is my personal impression that this decision was very much based > on short-sighted visual appeals rather than consistency and > usability issues, and that the amaroK devs try to justify it with > hindsight. Can anyone explain how to use the proper icon set? The new version just looks weird, especially on the menu on the left of the window. I can't see it under Settings->Configure Amarok->Appearance. Do I have a broken installation? I'm using the Kubuntu packages.
@Martin: It's kinda off-topic, but anyway, here we go. It's last option in Configure Amarok->General. I don't have a proper version of Amarok available at the moment, but I guess the checkbox is labeled with "Use Custom Icon Theme".
(Renamed the bug in order to better reflect its contents, and added version info for it.)
Re: Comment #7 I agree that this should not be closed. It is your bug so you should be able to reopen it, but I will do it for you. The way that this is done is seriously strange. The special Amarok icons which appear to be Crystal style are installed as HiColor and what appear to be HiColor icons are installed as CrystalSVG. I don't get it! Look in "$KDEDIR/share/apps/icons/" at: "player_playlist_2.png" & "amarok_playlist.png". Which is HiColor and which is Crystal? This in addition to the question of whether an app should install its own icons if they duplicate the functions of global themed icons. If so, these should be installed according to their style. Generic as HiColor and blue and fuzzy (:-) well they really are blue and fuzzy! :-D) as Crystal. IAC, I leave this to the HIC and/or TWG to figure out -- I will leave the bug open till they do.
I strongly agree with the call to follow the KDE standard by default. I like Amarok, but I mostly liked it because it looked like a real application, not like some kind of hard to use toy. Now, it gets more and more a non-standard app, providing it's own icons, a flashing highlight in the playlist (Where do I turn that monsterous thing off?!), superfluous highlighting tabs... I'm sorry. I like my applications to work and look predictable. If they can look nice and shiny at the same time, nice, but not at the sacrifice of consistency within the desktop please. Certainly not by default.
> IAC, I leave this to the HIC and/or TWG to figure out -- > I will leave the bug open till they do. To be fair: as amaroK is in extragear and not one of the core modules, I don't know if this decision is up to the TWG to decide, I still regard it as responsibility of the amaroK devs. Being able to take advice is another thing, let's see if the devs will be able to do that (after all, after one day the bug is already the 12th of open bugs, and regarding the number of votes and the controversy I agree that this bug should not be closed at this time).
I'd like to concur with many of the above statements. I like the icons and fully intend to use them as they will look good with my current colour and icon theme, but being having volatile taste in icon/colour themes will mean that i'll have to make the change in the amaroK settings in the future. It's not that I can't be bothered to change the settings to enable default icons, it's that if every application took this path I would have to change them for _each_ _application_ - diminishing one of KDE's finer points (easy themeing). I think you're being fairly pompous in converging from the standard - doubly so after so much controversy has been generated by so many knowledgeable KDE hackers. Please reconsider your decision to make these icons switched on by default. Thanks.
-20 votes from me. I like the new custom icons and as long as one can revert to the default icon set it's okay.
Re: Comment #18 What needs to be decided is what the requirement for being a KDE application are. The KDE libraries are GPL so there can be no additional requirements for using them. But, there should be requirements for being certified as a KDE application and these should be compliance with the KDE UI Guidelines. This should incluse use of styles, menu configuration, shortcut keys, as well as icon themes. To me, this is obvious, but one developer told me that he read the KDE Guidelines once and never looked at them again.
i think Tyrer is right. amaroK 2.x might very well be part of KDE 4.x, given it is likely KDE 4.x will allow official KDE apps an independent release schedule.
Well, it's not a bug, since it was intended to work that way.
> Well, it's not a bug, since it was intended to work that way. It is a bug, since something they have implemented is behaving wrongly. (At least, according to currently 647 votes.) I think the wishlist status is for things that are not yet included in the application.
> It is a bug, since something they have implemented is behaving wrongly It is behaving exactly as they intended, so it's a wish. Number of votes is irrelevant to decide if something is a bug or a wish. For amaroK, a bug is when something doesn't work as intended. Wishlists are requests to change the behaviour or implement new stuff.
If there is a misbehaviour I think it is a bug, wether it was intended or not. But it won't make any difference to this discussion if it's a bug or a wishlist item. I'd like to see someone from KDE's usability people take a look at this before amarok 1.4 gets released. I'll grep through the mailing-list of kde-usability to see if it was discussed there already and contact the list if they don't know yet about this bugreport.
by the way, i'd like to stress this is NOT a fight from the amaroK users to get rid of the new icon theme. i think the icons used to 'fill the blanks' in the standard KDE themes are great. also, personally i like the new icons. and fourth, this is not such an extremely important thing - its just the icons. on the other hand, we (if i may speak for the others here) do think it would be nice if those users, which changed their global icon theme, would see it reflected in amaroK. the current icons don't look very strange with crystal-like icons, but weird if you use for example the slick icon set. so - let me propose a middle way. if an user changes his global icon theme, let amaroK show the icons THE USER choose (of course, complete the icons he doesn't have in his theme with the amaroK ones). if the user did NOT set a custom icon theme, show the brand new amaroK icons. after all, its not like users won't understand them or get confused ;-) how about that?
Re: Comment #27: I don't see any problem with any app having custom icons as long as they are not enabled by default. However, an app needs to, at the minimum, provide all of the icons it needs in the HiColor style and optionally in whatever other style(s) that the developer wants. Currently, it is expected that in addition to HiColor, that CrystalSVG icons (the current default theme) be provided. This will probably change with KDE4 as the default icons theme is changing to Oxygen. In both HiColor and CrystalSVG, if the icons are new work, then SVGZ files should be provided in addition to 16x16 and 22x22 PNGs (larger PNGs can be provided at the option of the artist but the two small sizes are required). The PNGs must be hand optimized not just rendered with The GIMP or InkScape. So, AmaroK should not use its custom icons to "fill in"; the original purpose of HiColor was to fill in ("fallback" theme), but now that GNOME uses it as a theme, it is also used as a theme. I also note that that flashing liquid style status indicator should also not be enabled by default. Flashing should be configurable (PLEASE! :-) it drives me nuts) and the default style should be the user's chosen widget style. The three things needed in a desktop are: consistency, consistency, and consistency. :-D So, at least for the default settings, things should be consistent if possible.
i've discussed this before on irc and the amaroK blog, but i may as well add my input here as well so it's recorded here as well ... having this turned on by default diminishes consistency for -most- people. the default should be to use the system icons and certainly makes amaroK less integrated with the rest of the desktop which is a huge part of the reason people use KDE to begin with. yes, i understand the issue with icon themes and mismatched icons. i also understand that that is not the default KDE set up and therefore this setting is optimized for the -minority- of users who use KDE in a non-default setup. if they can figure out how to change their icon theme, they can change this. amaroK could turn these icons on by default if the icon theme is not the default theme though even that has problems as the icon theme may only replace, for instance, the file management related icons and use crystal for the rest (making the icon change in amaroK superfluous). as it is ... from a usability perspective, the default setting is currently wrong. having the feature there as an option is fine and justfiable, but the default needs to be rethought.
i like the flashing liquid style alot. i would even vote for a liquid style of the normal selection of the playlist, which wouldn't flash and have a bit different color pitch then to indicate that it isn't currently playing but only selected. however, liquid selection style should be enabled by default and configurable so it can be disabled. as for the icons, the crystal icon maker have had an idea to include amaroks custom icons into his theme and let amarok use the system icons. if the user then choose crystal icons, then amarok would use its shiney custom icons which would match the crystal icon set. otherwise, if the user selected another icon style for KDE, however, amarok would have to use those icons. :)
Please keep the flashing liquid style status indicator out of this bug. It may be an issue, but if so there should be an own bug for it, this one is about the custom icons.
Re: Comments 30 & 31: Actually this is the same issue. amaroK does not use the KDE style defaults. AJS is correct that this should not be the default behavior, but can be a user configurable option. We have to consider how the supposedly integrated KDE DeskTop would look if every KDE application had its own icon and widget styles.
Re: Comments 30 & 31 & 32 The system listview selection style is used for marking selected songs in amaroK's playlist. But the song currently being played is different from a selected song (e.g. you could remove a selected song from the playlist by pressing Delete). As it is now, you can even distinguish if the current song is selected or not. Thus, the liquid style indicator for the current song does make a lot sense from a usability perspective: use different indicators for different things. (If it has to be animated, is a different matter, though.) But I clearly have to agree with #31: this should be discussed as a different bug.
Icons are disabled by default. you don't need to use them. Hence, this report is invalid. Closing. DO NOT REOPEN.
Oh, wow. That's awesome. I think that makes for a good incentive for me to finish the amaroK icons in Lila, and we're all good friends again, right? :)
Re: Comment #34 If this has been fixed, shouldn't the report be tagred as: RESOLVED FIXED?
love, seb ;-)
RESOLVED INVALID? C'mon, it was fixed! This is getting silly.
> RESOLVED INVALID? C'mon, it was fixed! This is getting silly. Really, it doesn't matter as long as it's fixed. Let's think about the correct resolution after we have to reopen it for 1.4.1 when they have the complete custom icon set together and re-enable it again ;-) Till then, I'd like to have no more comments here, as everything's ok now.
Perhaps this whole discussion should have been moved to the KDE wish list. Providing a way for applications to have complete and consistent icon sets when the current default icon set doesn't provide all of the icons it requires is more of a KDE issue than an amaroK one. It surely effects many applications. Sorry - no intention to reopen this particular flame but I don't think the issue will go away. Where should this wish *really* be posted?
Regression activity: http://websvn.kde.org/trunk/extragear/multimedia/amarok/src/amarokcore/amarok.kcfg?r1=550786&r2=550787 Please reopen this bug.
Well, it was clear they would re-enable them. Btw, I'm still waiting for someone of the kde-usability team to comment in favour of this decision. (As opposed to Thomas Zander and Aaron Seigo, who already expressed their views in opposition of it.)
The proper way to fix this consists of two steps; 1) make a kde-wide naming scheme for media-icons. This includes action/media_forward for example. To make it a default iconname means amarok can use the kde-wide default icons since a theme like Oxygen will ship them and other themes can provide them as well. Using 'media' instead of 'amarok' in the names will mean other applications can benefit from these icon as well. This step is set in motion already. The artists have told me they will include these icons in Oxygen. 2) the second step is to enhance the icon-loading a little bit for KDE4 to make sure that if actions/media_forward is not found KIconLoader will try to search for actions/forward next. _inside the same theme_! This part allows applications like amarok to use the default without using problematic tings like their own icon name-space and config settings.
IMHO all KDE apps should use one iconset (default or user defined) so that all applications look consistent. If the icons the application needs are not in the icon theme the user uses I expect the application (in this case amaroK) to partly use own replacement icons. Thus the main part of the application (amaroK) looks consistent to the rest of the KDE applications. For me that is more important than a default consistent look inside the program itself. BTW: The option "user definded icon theme" really does mean "amaroK maintainers definded icon theme", doesn't it? "User defined" icon theme IMHO is the one the user chose as KDE icon theme. Oh - and regarding consistency in amaroK itself: your icon theme isn't complete: help and quit use the icons of the KDE theme, also do listview and treeview in the collection tab and the files, folders and navigation buttons in the files tab, the icon on the search field button and the amarok icon on the menu button.
(Updating version info from 1.4-beta3 to 1.4.1. Current vote count: 959.)
The option should really read: Implement hack to map themable icons in Amarok to unthemed system icons. The thing is, the icons in Amarok are themable just fine. The reason we chose to do this is really quite simple: After six (yes, six) months of attempting to get icon artists to help us get icons made for the actions we require, we gave up finding someone who could make Crystal icons, and decided in stead to be consistent within Amarok itself, in stead of having something half-done. The option to map the icons to icons already present on the system shows you why we chose to do this: It maps to icons that exist in Crystal already, but you will notice that these icons do not represent the functionalities very well. We have tried to find the ones that make most sense, but quite frankly, there simply does not exist enough icons for this. So: This is not a custom icon theme in the classical sense - these are perfectly themable freedesktop.org-icon-theme icons. A list of the icons used in Amarok can be found on the Amarok wiki right here: http://amarok.kde.org/wiki/Artist_team:Icon_List What Thomas Zander proposes above would be ideal - a system-integrated fallback mechanism so we wouldn't need the hack that Amarok currently implements, and simply do it automatically. Basically: Look for actions/amarok_next, if not there look for actions/media_next, if not there look for actions/next. It could even be made so far as to make this automatic, as in make this possible to do simply by making the icon loader accept a category. It might then look for icons in the following order: application_iconname -> category_iconname -> iconname. Sorry, that was a bit rambling, but i wanted to get it down before i forgot again ;)
Re: Comment #46 A kdelibs bug has to be filed then, right? As a side note, did you (during the six months you mentioned) ask Everaldo to make you Crystal SVG-style icons?
> As a side note, did you (during the six months you mentioned) ask Everaldo to > make you Crystal SVG-style icons? Not that Everaldo has much to do with upstream KDE icons, nowadays. But the current KDE Artists team does an amazing job too :)
Ok, here's what's new in KDE 4: * We now have media-* icons in the Oxygen icon theme, as defined by the icon naming specification (e.g. media-playback-start, media-skip-forward or media-eject) which should provide a reasonable base set for media players. Yeah, we even have a few more icons which I would like to have killed but could not do that in time, which means that other nice icons are also in the base theme and will stay there for the lifetime of KDE 4. * Plus, we also have a fallback mechanism, also as defined by the icon naming specification. For example, you could include a "media-playback-start-amarok" icon that's not so nice than the Oxygen one but more branded, and install it in the Oxygen namespace. If another theme doesn't have this icon then it will fall back to "media-playback-start", or "media-playback", or "media". (Just for demonstration purposes, reasonable themes won't have the two last ones.) Not sure if that gets you anywhere - I didn't quite get the feature request for fallbacks anyways because your custom theme was specifically designed not to change even if other themes are selected. Anyways, that's what KDE 4 provides. Personally, I hope you won't use that functionality at all and stay on pure Oxygen style by default.
Why was this reopened? Here's the deal, and consider it the final words on this topic (no more reopening): 1) Amarok 1.x is frozen except for bugfixes. 2) In 2.x the Oxygen icons will be enabled by default.
The reopening actually occurred more than a year ago, back when this was still a hot topic.