Friday, March 9. 2007
Amarok2 with Oxygen icons
Today I've made Amarok2 use the new Oxygen icons from SVN trunk. Have a look:
I'm rather fond of Oxygen; I think it's an improvement over Crystal, and definitely feels refreshing. Unfortunately even Oxygen can't solve some of our fundamental problems with icons:
I'm rather fond of Oxygen; I think it's an improvement over Crystal, and definitely feels refreshing. Unfortunately even Oxygen can't solve some of our fundamental problems with icons:
Amarok needs many very specific icons, like "Update Collection", "Cover Manager", or "Visualizations". We would need someone to create these icons for us.
Our release cycle is independent from KDE's. Sometimes we introduce a new feature that needs an icon. Relying purely on Oxygen, we would need to wait for the next KDE release to get a suitable icon.
The biggest problem: KDE allows users to switch to alternative icon themes. Most likely they're incomplete as far as Amarok is concerned.
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Please don't introduce another incosistency to Linux desktop! This is one of biggest advantages of Linux desktops over Microsoft Windows - that everything (targeted for your platform - e.g. KDE) uses same style and icons, which you can choose generally for whole desktop. I don't want gazillions of different applications with different icons and themes like in Windows world.
Make Amarok use default KDE style and icons! If somebody chooses another non-standard icon theme which doesn't include all icons needed by Amarok, it is his problem, not yours.
Make Amarok use default KDE style and icons! If somebody chooses another non-standard icon theme which doesn't include all icons needed by Amarok, it is his problem, not yours.
Main action icons (Play, Stop, Previous track, Next track) are way too small and hard to find not only for a new user but even for someone used to Amarok. This should not be default.
No worries, that's just a technical problem with our toolbar. Going to be fixed.
I agree 100%. Play/Pause/Next/Prev are the most important buttons when playing music. They need to be visible.
Mark, have you asked the Oxygen guys about making the extra icons for you? It seems to me that if the Amarok default icons match the KDE default icons, most users will be satisfied.
Well then the question is what happens when we have to add another icon. So then kdelibs-4.0.2 would have the icon, and users with kdelibs-4.0.1 would have a blank icon instead.
I could see this resolve by Amarok bundling all the Oxygen icons, kind of like we do now.
I could see this resolve by Amarok bundling all the Oxygen icons, kind of like we do now.
As far as I see it, one solution would be to indeed bundle the icons, and check whether the icon theme contains the appropriate icon. If not, load from the bundled icons.
I think bundling is a good idea. Are there any inherent problems with that approach?
Hang on, this highly confuses me.
The kdelibs and the artists agreed that oxygen and KDE4 would allow for fallback icons in a more general manner many months ago.
The idea was; you do a KIcon("foo_bar"); and the icon is looked for in the following places
1) foo_bar in the current user icon set.
2) foo in the current user icon set
3) foo_bar in the desktop-global icon set.
4) foo in the desktop-global icon set.
This allows you to ask for a 'multimedia_play' icon and get the amarok specific one, or the one that is a 'play' icon when the iconset does not supply the amarok specific one. Based on the reasoning that its better to get a 'play' that fits then a 'multimedia_play' that does not the users selected iconset.
I proposed this solution after we talked at the KDE-NL multimedia meeting and I'm entirely disappointed that while everyone agreed this to be a good thing we now see a public blog saying things still suck. I can imagine it falling though the cracks, but please address it, and don't kick the establishment again. That's not a good way of working together.
The kdelibs and the artists agreed that oxygen and KDE4 would allow for fallback icons in a more general manner many months ago.
The idea was; you do a KIcon("foo_bar"); and the icon is looked for in the following places
1) foo_bar in the current user icon set.
2) foo in the current user icon set
3) foo_bar in the desktop-global icon set.
4) foo in the desktop-global icon set.
This allows you to ask for a 'multimedia_play' icon and get the amarok specific one, or the one that is a 'play' icon when the iconset does not supply the amarok specific one. Based on the reasoning that its better to get a 'play' that fits then a 'multimedia_play' that does not the users selected iconset.
I proposed this solution after we talked at the KDE-NL multimedia meeting and I'm entirely disappointed that while everyone agreed this to be a good thing we now see a public blog saying things still suck. I can imagine it falling though the cracks, but please address it, and don't kick the establishment again. That's not a good way of working together.
Thomas, what do you propose to do for specialized icons. I doubt if there would be a logical fallback for something like "cover manager." I'm sure this isn't just an Amarok problem. Will all icon sets have every icon for a program like Krita? They've had to make their own icons as well.
Hi Louis.
To be clear; my point above was mostly directed at the last bullet point of the blog.
As to your question; this is not really a problem at all. And never has been. Your application ships icons for "cover manager", just like Krita ships icons for "Gradient Tool". There is no inconsistency if the user switches to a different icon set. Not more then any other app. The icon set has to do additional work for all apps it supports. Again, nothing new.
The problem we had last year was when amarok made general-purpose icons (play, next etc) into app-specific icons and shipped those. This is a distinctly different problem and one that is addressed in the solution I wrote about above.
If you are still uncertain, please contact me on irc or via mail.
To be clear; my point above was mostly directed at the last bullet point of the blog.
As to your question; this is not really a problem at all. And never has been. Your application ships icons for "cover manager", just like Krita ships icons for "Gradient Tool". There is no inconsistency if the user switches to a different icon set. Not more then any other app. The icon set has to do additional work for all apps it supports. Again, nothing new.
The problem we had last year was when amarok made general-purpose icons (play, next etc) into app-specific icons and shipped those. This is a distinctly different problem and one that is addressed in the solution I wrote about above.
If you are still uncertain, please contact me on irc or via mail.
Wow! It looks great. Not so much comic style. I really love it. Great work!
Keep on rocking, guys! And take your time
Keep on rocking, guys! And take your time
It's maybe possible to create a theme package system for Amarok2, including the style for the sidebar, the splash screen and the icons.
There is already a way to choose a style in the UI, so this will only extend the current theming feature.
So provide a Oxigen theme package by default and let the community share their other package with icons and graphisms adapted for alternative theme...
BTW, will it be possible in Amarok2 to move the toolbar ? At least to place the play/stop/next... buttons on the bottom ?
There is already a way to choose a style in the UI, so this will only extend the current theming feature.
So provide a Oxigen theme package by default and let the community share their other package with icons and graphisms adapted for alternative theme...
BTW, will it be possible in Amarok2 to move the toolbar ? At least to place the play/stop/next... buttons on the bottom ?
it's a bit harsh to say that "it's awful"... but I must admit I prefear the old interface. I hope it will be possible to hide some a lot of elements or to have a "minmal mode" view with just the sidebar and the current playlist
The Oxygen designers really want to create all the icons you need. I mentioned this several times to various Amarok developers, but somehow did not get any response.
Whenever you need to add new icons later, you can simply bundle your new icon in Oxygen style. Use a fallback icon if possible. You should then also submit the needed icon to the artist mailing list, so that it can be registered in the icon naming spec and included in future icon themes.
Users who use an incomplete icon theme will see the Oxygen-style icon in more applications than Amarok only. For them, you can provide an option to use an Amarok-specific icon theme. But this setting should not be the default, because
a) most users will actually choose an icon theme that mixes well with Oxygen icons.
b) some users with disabilities such as low vision need to use high contrast (monochrome) icons, which does not work reliably if applications ignore the KDE settings by default. If you do not wish include a monochrome version of your new icon yourself, then the missing icon can be automatically converted to monochrome with a clever icon effects setting in KDE.
c) the default settings of KDE and Amarok should not be inconsistent: Users who change the KDE default setting are more likely to also change the Amarok setting than users who did not change any settings at all.
So, please contact the Oxygen team. They are extremely interested in helping you.
Olaf
Whenever you need to add new icons later, you can simply bundle your new icon in Oxygen style. Use a fallback icon if possible. You should then also submit the needed icon to the artist mailing list, so that it can be registered in the icon naming spec and included in future icon themes.
Users who use an incomplete icon theme will see the Oxygen-style icon in more applications than Amarok only. For them, you can provide an option to use an Amarok-specific icon theme. But this setting should not be the default, because
a) most users will actually choose an icon theme that mixes well with Oxygen icons.
b) some users with disabilities such as low vision need to use high contrast (monochrome) icons, which does not work reliably if applications ignore the KDE settings by default. If you do not wish include a monochrome version of your new icon yourself, then the missing icon can be automatically converted to monochrome with a clever icon effects setting in KDE.
c) the default settings of KDE and Amarok should not be inconsistent: Users who change the KDE default setting are more likely to also change the Amarok setting than users who did not change any settings at all.
So, please contact the Oxygen team. They are extremely interested in helping you.
Olaf
Please don't see me as distracting factor again, I don't want to restart the discussion the way it went, and I'll try to keep out of the debate as much as is reasonable. However, there are good answers for all three of your points:
Point 1. I think Olaf has already answered this one perfectly, no need to go into that further. Just remember that you got a complete custom icon set made by volunteers, so you're quite likely to get some help from either these or the Oxygen team, or maybe both could collaborate on Really Rocking Oxygen Icons.
Point 2. When you release a new version that relies on not so recent kdelibs, just include all the Oxygen icons in Amarok that are missing from this kdelibs release. With standard icon names, of course.
Point 3. I'm still not sure why you see it as a problem that KDE allows users to switch themes. Anyways, let's try it with an analogy... You sure know that some web sites are doing browser checks for displaying a site or not, or having all site features included. If you're using Konqueror (like me, for example) this is plain annoying, because Konqueror actually does most sites better than they think it does. So, user agent string checking is a bad thing, because it tries to care about things that it should not care about, and should rather leave bugfixes for the website rendering to the browser vendors. Web sites should not do it themselves.
Your situation might derivate in a few details, but on the whole it's the same story. It is not your responsibilty to care about missing icons in other icon themes. It is your responsibilty to care about great defaults, and maybe to care about great defaults not only in Oxygen but also in a couple of important distribution (although this is already arguable). It is absolutely not your responsibility to care about every single damn icon theme that's out there, and assume most of them are not good enough. It is the users' responsibility to select their icon theme, and it is the theme's maintainer's icon theme to get it consistent. It is your responsibility to fucking stay out of this issue if it doesn't concern the defaults. You don't do anyone good with this.
So get a great set of great Oxygen icons into kdelibs, and the ones that are missing or not good enough shall be replaced by the ones bundled with Amarok. Just do me a favour and set that custom theme checkbox to not enabled by default.
Point 1. I think Olaf has already answered this one perfectly, no need to go into that further. Just remember that you got a complete custom icon set made by volunteers, so you're quite likely to get some help from either these or the Oxygen team, or maybe both could collaborate on Really Rocking Oxygen Icons.
Point 2. When you release a new version that relies on not so recent kdelibs, just include all the Oxygen icons in Amarok that are missing from this kdelibs release. With standard icon names, of course.
Point 3. I'm still not sure why you see it as a problem that KDE allows users to switch themes. Anyways, let's try it with an analogy... You sure know that some web sites are doing browser checks for displaying a site or not, or having all site features included. If you're using Konqueror (like me, for example) this is plain annoying, because Konqueror actually does most sites better than they think it does. So, user agent string checking is a bad thing, because it tries to care about things that it should not care about, and should rather leave bugfixes for the website rendering to the browser vendors. Web sites should not do it themselves.
Your situation might derivate in a few details, but on the whole it's the same story. It is not your responsibilty to care about missing icons in other icon themes. It is your responsibilty to care about great defaults, and maybe to care about great defaults not only in Oxygen but also in a couple of important distribution (although this is already arguable). It is absolutely not your responsibility to care about every single damn icon theme that's out there, and assume most of them are not good enough. It is the users' responsibility to select their icon theme, and it is the theme's maintainer's icon theme to get it consistent. It is your responsibility to fucking stay out of this issue if it doesn't concern the defaults. You don't do anyone good with this.
So get a great set of great Oxygen icons into kdelibs, and the ones that are missing or not good enough shall be replaced by the ones bundled with Amarok. Just do me a favour and set that custom theme checkbox to not enabled by default.
new ui design really sucks
for ex. if i wanna load media from collection to playlist i have to drag it through lyrics/artist
main thing is the playlist but not additional info
make option to get old design back please
for ex. if i wanna load media from collection to playlist i have to drag it through lyrics/artist
main thing is the playlist but not additional info
make option to get old design back please
New GUI is less cleaner than the old one. It's too overloaded of options.
portant for aAbout the Oxygen icons, I don't believe it's something real immarok, if you don't have an icon for some option, just do it yourself, or use an existing one.
Sorry for the poor English, and keep the good work.
portant for aAbout the Oxygen icons, I don't believe it's something real immarok, if you don't have an icon for some option, just do it yourself, or use an existing one.
Sorry for the poor English, and keep the good work.
My English isn't so poor, it just the message didn't display right:
New GUI is less cleaner than the old one. It's too overloaded of options.
About the Oxygen icons, I don't believe it's something real important in amarok, if you don't have an icon for some option, just do it yourself, or use an existing one.
New GUI is less cleaner than the old one. It's too overloaded of options.
About the Oxygen icons, I don't believe it's something real important in amarok, if you don't have an icon for some option, just do it yourself, or use an existing one.
I think there's no need to change the GUI. The old one was so good and I think you should work to improve amarok 1.4's GUI...
What for i need "now playing" http://static.kdenews.org/content/the-road-to-kde-4/vol12_4x_amarok.png
at the center of the screen that occupies 70% of the screen?! Do you think users are so stupid that cannot understand that highlighted line in playlist is playing?!
Also why did you move buttons to the up left? Is it for mac users? Dont you think amarok is mostly linux player.
Users need to listen the music and not to "rediscover" how to disable unused features.
at the center of the screen that occupies 70% of the screen?! Do you think users are so stupid that cannot understand that highlighted line in playlist is playing?!
Also why did you move buttons to the up left? Is it for mac users? Dont you think amarok is mostly linux player.
Users need to listen the music and not to "rediscover" how to disable unused features.
A lot of negative comments there... I'd just like to say that, while the shot above may not be amazing (as you'd expect from a dev version), I really like the mockup that appeared on the Dot (http://dot.kde.org/1173761811/). And I agree with Olaf about the icons.
Amarok Links
Calendar
|
September '08 |
|
||||
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | |||||
Quicksearch
Archives
Categories
Syndicate This Blog
Blog Administration
We Listen To...
Powered by
