GNOME Bugzilla – Bug 380896
Tango icons for Rhythmbox and other Players
Last modified: 2018-05-24 12:09:48 UTC
Rhythmbox currently uses a few outdated icons that should be replaced by Tango icons. It would be nice to take the opportunity and create a "media players" set similar to ArtLibreSet¹, with icons that can be used by other players, too.
Icons that are currently needed by Rhythmbox:
Application icon (all sizes)
=> needs a nice metaphor
Tray icon (22x22)
=> should perhaps reuse the application icon?
=> should perhaps provide a disabled state for "not playing"?
- Show/Hide Browser (I vote for removing this toggle button!)
Sidebar (currently 24x24, but should better be 16x16 to match Nautilus sidebar)
- Library (Pile/Shelf of books or CDs?)
- (Static) Playlist (Something reflecting a list of songs)
- Automatic Playlist (Like Playlist, but also reflect "automatic")
- Song queue (action reflecting enqueing or playing after another? hard...)
- Podcast (Look what Banshee² and iTunes³ have, should probably be similar)
- Internet radio
- Last.fm radio (Can the Last.fm logo be used? Something not too different?)
- DAAP share (Perhaps reuse the BNC connector from the current shared folders and something reflecting music on top of that?)
- Eject (To eject CDs and DAPs -> look at your stereo)
(In reply to comment #0)
> Tray icon (22x22)
> => should perhaps reuse the application icon?
This really depends on what the application icon is, but in general I think it would be a good idea.
> => should perhaps provide a disabled state for "not playing"?
Whether this would work obviously depends on what the tray icon looks like.
> Sidebar (currently 24x24, but should better be 16x16 to match Nautilus sidebar)
I'll take a look at what it looks like with smaller icons.
> - Library (Pile/Shelf of books or CDs?)
There's some discussion about changing the source list so that "Library" is just a group header, with the Music source inside it. So we may not need this in the future.
> - Song queue (action reflecting enqueing or playing after another? hard...)
I'm not sure what the icon would look like, but one for this would be nice.
> - Last.fm radio (Can the Last.fm logo be used? Something not too different?)
It should probably use a small version of the logo - I've been meaning to look at it, but hadn't found the time.
> - Eject (To eject CDs and DAPs -> look at your stereo)
Tango already has one of these, and we use it.
Created attachment 79618 [details]
feed-podcast in 16x16 and 22x22
I was thinking of using those from Banshee first, but those are MIT-licensed as Banshee itself, so I drew a gpl one. (or is it ok for rmbox to ship mit-icons?)
Created attachment 79634 [details]
playlist in 16x16 and 22x22
Created attachment 79645 [details]
playlist in 16x16, 22x22, 32x32 and 48x48
Created attachment 79651 [details]
playlist-automatic in 16x16 and 22x22
Created attachment 79695 [details]
radio-station and radio-station-new in 16x16 and 22x22
Sorry for the flood. :)
Created attachment 79957 [details]
internet-radio and internet-radio-new
In all sizes made by Josef Vybíral.
@Michael and James
A MediaLibreSet could be a good idea, someone should join tango mailin list and propose something. But IMHO this icon set should be more generic, more multimedia then music. This mean include stuff related to video, audio and picture (both playing and production) and keep specific stuff in RB (for example ban/love in last.fm). A good example of generic multimedia icon set come from stockicons.com - see for example http://stockicons.com/detail/193
By now Rhythmbox could use the custom themeable app icons trick: see http://live.gnome.org/ThemableAppIcons for more info. Using the proper names for custom named icons, we will be able to switch to future MediaLibreSet when it will be ready.
By now IMHO rhythmbox can provide those icons:
* actions/love-song (last.fm)
* actions/ban-song (last.fm)
* actions/skip-song (last.fm)
This is just a starting list, using contexts and name scheme from Icon Naming Spec.
I checked the current stock icons code in rhythmbox sources. It's really outdated and don't use any named icon facility. I think we need to rewrote it from scratch. Of course we have to define in advance which stock items Rhythmbox will need. I think using something like in current Epiphany code is the best option.
Not sure, but did you added a gradient for each "row" ub playlist icons? If so, isn't better use flat colors for each row and put a single light (white to transparent, top to bottom) gradient over all rows?
Nope, they are just semi-transparent objects on top of a gradient, so they pick up the "light" from the object beneath.
Sorry for taking so long to comment on this. The icons look pretty cool.
Rewriting out icon-handling to do things the proper way would be good idea. It would also make it possible for plugins to add an "icons" dir under their global and user-specific directories for plugin-specific art.
Regarding the icons from Banshee, using MIT-licenced stuff is fine, although I don't think it actually matters too much for most licences (that deal with code issues) since we don't actually "link" the art to the program.
As part of some other work, I've added two directories to the gtk icon search path - $pkgdatadir/icons (/usr/share/rhythmbox/icons, typically) and ~/.gnome2/rhythmbox/icons/, which allows plugins to install their own icons.
Created attachment 84400 [details] [review]
use internet-radio and internet-radio-new icons
extract internet-radio.tar.gz (from comment 7) in plugins/iradio/icons/hicolor to get the actual icons in the right place.
Looks good to me, aside from a typo in the name of "internet-radio-new.png" (it's "intenet-radio-new.png"). I'd be happy for this and the other icons to go in, and get some feedback on the actual art on the mailing list.
(In reply to comment #13)
> Looks good to me, aside from a typo in the name of "internet-radio-new.png"
> (it's "intenet-radio-new.png"). I'd be happy for this and the other icons to go
> in, and get some feedback on the actual art on the mailing list.
OK. I'll start committing them on trunk under data/icons and installing under $prefix/share/rhythmbox/icons/hicolor. I'll follow naming sheme in comment 8.
All icons in previous comments are now on trunk. I've also committed changes to plugins/iradio/rb-iradio-source.c from Johnathan (comment 12).
scalable: library-podcast, playlist-automatic
32x32: library-podcast, playlist-automatic
24x24: I'll create them from 22x22 later
@Andreas: just 0.2 - what about increasing the rows in large playlist icons? I mean, increase from 4 to 6 rows in 32x32 and from 2 to 8 in scalable. Larger icon, more entries :-)
@James: I didn't add credits for Andreas and Josef in ChangeLog. May I add the "artists" property to GtkAboutDialog?
Forgot to mention: I think is better to place all common icons in a single hierarchy, instead splitting them in plugins/ directories, at least for always-build plugins as iradio. For example, the icon for visualizer plugin is inside plugins/visualizer directory: it's the right place, 'cause this plugin needs GST-10 to build. Same for future audioscrobbler icons: you can disable this plugin at configure time, so icons should be installed only if this plugin is enabled.
Created attachment 84720 [details] [review]
use new library-podcast and playlist* icons
I simply changed references to existing macros/defines/other. The code to lookup for icons in rb-stock-icons.c is still the same, so I'm not sure, for example, that 16x16 pixmaps will be used in Music->Playlists menu. It's more a workaround than a real solution to icon lookup.
Created attachment 84721 [details]
A rhythmbox/trunk screenshot using new icons
Created attachment 84735 [details] [review]
Updated this patch to have one place that we define the icon size. So, none of the icons show up for me because we use 24pix icons for most everything.
Oh, so apparently this 22pix thing was actually a design decision for the Tango themes:
48, 16, and umm 22. Genius.
William: the 22x22 size was decided because of compability with kde. We can therefore just add a 1 pixel around all images with imagemagick so it works well under gnome, clipping parts out of images on the other hand don't work. As luca said, he's going to generate those 24x24 images, unless I beat him to it.
Andreas, I don't mean to offend anyone - the icons looks awesome. But the logic for using 22x22 icons is really lacking. You should have make you spec self consistent with multiples of 8. As you point out KDE would have had an easy time adding a pixel to make their icons meet the spec. However, GNOME has to recreate all of our icons because cropping isn't an option. And in the process we make a really important GTK+ API useless. Not a good design decision. But whatever pointless now I suppose...
Since this patch was applied to SVN, the radio icon has completely disappeared from the source list (it can still be selected, but there's just no icon there).
The patch hasn't been committed yet. With the patch, some icons don't appear to work uninstalled (but work fine installed).
(In reply to comment #23)
> The patch hasn't been committed yet. With the patch, some icons don't appear to
> work uninstalled (but work fine installed).
Hmm, well, according to the ChangeLog, *something* was committed, because after this change:
2007-03-16 Luca Ferretti <email@example.com>
* plugins/iradio/rb-iradio-source.c: (rb_iradio_source_init):
Use new custom named icon for IRadio in source list and in
NewRadio item. Original patch from Jonathan Matthew.
2007-03-16 Luca Ferretti <firstname.lastname@example.org>
Added new icons directory to provide custom themeable icons for
Rhythmbox; see bug #380896 for detail. Also added available
pixmaps from the same bug, but still unused in code.
my iradio icon disappeared even when running installed.
Why aren't we using 16px source list icons? 22px is supposed to be for toolbars, I think.
Is there any chance to see this icon, based on the new gtk-cdrom icon, used for the browser button?
Created attachment 85862 [details]
icons taken from gtk
*** Bug 426629 has been marked as a duplicate of this bug. ***
Created attachment 85909 [details]
Application icon in all sizes by Hylke Bons and myself. Heavily based on Garretts icon from Bluecurve. Thought it was about time to finish it as it started popping up here and there on the net.
We could use that for the tray icon too. If we do that, we could also use a version without the blue sound wavy things to indicate playing/not playing status (bug 314608).
Created attachment 87053 [details]
without the blue waves for "not playing"
Hope this works.
At 16x16, it's quite a subtle difference. I barely notice it changing if I'm not looking directly at the icon and I already know what I'm looking for. Maybe that's a good thing, though. Once you know what you're looking for, a quick glance at the icon is all you need to figure out which state it's in, which is good.
Created attachment 87584 [details] [review]
use more of these icons
- use the new app icon
- switch between 'rhythmbox' and 'rhythmbox-notplaying' for the tray icon depending on state (bug 314608)
- use the new podcast icon
- use the playlist and playlist-automatic icons
- move the rating star and eject icons into data/icons/
- only inline the star icons since we can live without the rest
- when --enable-uninstalled-build is used, add the source directory to the icon search path (need to do 'ln -s . hicolor' in data/icons/ for this to actually work for now)
tar file containing all the new and moved icons to follow.
Created attachment 87585 [details]
new and moved icons
extract this in the root of the rhythmbox source tree.
Does playlist-automatic exist in 32x32 and 'scalable' sizes? It doesn't seem to appear in menus without the scalable version.
(the patch to use the iradio icons was committed some time ago)
The patch/tarball looks great to me, although the icons don't appear to work when running uninstalled.
I unpacked tha tarball as described and applied the latest patch. Builds fine, make install works fine, started rhythmbox and most icons are missing now (playlists, queue....). James, is this the same you are seeing when running uninstalled?
(In reply to comment #37)
> I unpacked tha tarball as described and applied the latest patch. Builds fine,
> make install works fine, started rhythmbox and most icons are missing now
> (playlists, queue....). James, is this the same you are seeing when running
If you're not using --enable-uninstalled-build, did you update the GTK+ icon cache?
If I 'make install' with this patch manually, the icons don't appear until i've done it.
Well I did
gtk-update-icon-cache -f /opt/gnome2.20/share/icons/hicolor
now, but the icons still don't show up.
Jonathan: sorry, seems I forgot about those two sizes for that icon. It's in the works.
Created attachment 87945 [details]
playlist automatic in 16x16, 22x22, 32x32 and 48x48
There that should be all. Just poke me if something else is missing.
I've committed these new icons and the code changes to use them.
I've also moved all the icons so they work in uninstalled builds.
It still doesn't work for me... No icons for:
- Auto Playlists
Buth in the menus and in the main interface...
just a note to say it misses a tango icon for "missing files"
(In reply to comment #44)
> It still doesn't work for me... No icons for:
> - Queue
> - Podcast
> - Radio
> - Playlists
> - Auto Playlists
> Buth in the menus and in the main interface...
I have this problem too, debugging on IRC with Jonathan we have found what appears to be an issue with the version of hicolor-icon-theme, places and status (where those icons are found) were only added in hicolor-icon-theme-0.10 and later according to:
Fedora Core 6 (for example) only ships with hicolor-icon-theme-0.9.2-1, so we need a workaround for older systems.
Alex, that sounds right to me. I was using 0.9 and I wasn't seeing the RB icons. I updated to 0.10 and they work now.
I was getting 0.9 from jhbuild. So, I've updated the moduleset to provide 0.10.
I'm back :-) Any pending task?
I'm going to prepare the patch to add Artwork tab in About -> Credits. Could someone provide me the list of contributors?
Also it seems to me that playlist*-new are missing, isn't it?
playlist-new, playlist-automatic-new, podcast-new.
If someone was to replace the visualisation icon I made with something that actually looks good, I'd be thankful.
Some new icons for random, repeat and browse would be cool, too.
Fantastic work, BTW. Rhythmbox now looks as it deserves.
Created attachment 89052 [details]
Various *-new icons
Seeing that it was me who filed the bug in the first place... here are he "-new" variants for playlist, playlist-automatic and podcast.
Created attachment 89053 [details] [review]
patch to use them
Created attachment 89054 [details]
tar file containing the icons
extract this in the rb source tree root to get the new *-new icons in the right places with the right names
Argh... I also did the patch to use the new icons, but forgot to upload the second attachment, sorry :(
Attachments 89054, 89053 are now commited; 89052 should be deprecated by 89054.
the stars on podcast-new and radio-new icons have different sizes in
rhythmbox from svn 5132. could you make them more consistent?
Created attachment 89065 [details]
22x22 icons with diferent star emblem
@Björn: only in the 22x22 version. Are those even used somewhere? Anyway, I actually took the star from document-new in gnome-icon-theme, so this is the same size as the rest of gnome uses. But, at least for podcast in 22x22, the star seems a big bit...
Here's a tar which has both the radio-new with the big star, as well as the playlist-new, playlist-automatic-new and podcast-new with the smaller one. See what you like better.
they are used in the tool bar.
Made a page in the gnome wiki describing the names, this makes it easier to track the names when we're doing highcontrast icons (just started on the radio).
Please help fill out the Description/Usage field.
Created attachment 89248 [details]
Last.fm, Jamendo and Magnatune icons
I redid the Last.fm, Jamendo and Magnatune icons using Tango look (but using the original colors). I think they look nice in rhythmbox as the size and general look is closer to the rest of the icons.
Good effort, Michael.
My only comments would be to firstly check that we have the relevant rights within the branding licenses to manipulate these logos.
Secondly, the outside highlighting is a bit off-standard. This looks a bit too stripey. The outer highlight should be 20% value (as in Hue-Saturation-Value) of the base colour and the inner highlight should be much more subtle.
I've made some changes to the Last.fm and the Jamendo logos. The magnatune one needs a bit more work to get right.
Created attachment 89256 [details]
Last.fm, Jamendo and Magnatune icons (v2)
So the only problem here is that plugins can't support icon themes yet. Tango-ifying these for now can't do much harm.
Also, these may need adjustments to actually fit 22x22. Currently, they are the old GTK size, 24x24.
Created attachment 89259 [details]
Screenshot of new Last.fm, Jamendo and Magnatune icons in use
Plugin-specific icons are themeable. They just need to be placed in plugins/$plugin/icons/hicolor/$size/$context in the source tree and installed in $pkgdatadir/icons/hicolor/$size/$context like other icons.
Created attachment 89262 [details]
HighContrast-icons for these actions. Perhaps I've should have opened a new bug about this, but lazy as I am I'm attaching them to this report instead ;)
Do we need a application icon as well?
Luca, I guess you're in charge of these.
I meant that if the plugin is to be distributed standalone, for example, the icons can't be themeable (because the distribution is restricted to ~/.rhythmbox/plugins/$plugin/ or /usr/lib/rhythmbox/plugins/$plugin).
Maybe GTK has some support for "external" icon stores where a proper theme-dependent lookup procedure can take place. If it doesn't, it would be nice in the future.
Does someone want to start committing and updating the status of patches? There's a lot of work done here!
Not that we really support separately distributed plugins all that much, but they could either install icons to ~/.gnome2/rhythmbox/icons or add their install location to the icon search path.
Alex: I did those icons on 22x22 and then added 1px to each border because I was under the impression that 24x24 is actually needed here... for whatever reason, it looks right. Anyway, if 22x22 is needed that border can just be removed.
Concerning trademarked artwork, only the last.fm icon includes the original vektor "a" sign, if that is a problem it can easily be replaced. If general "likeness" is a problem, those icons could also be modified to just "similar" to the original artwork to be recognizable (what GNOME did with the acrobat logo after Adobe complained).
(In reply to comment #57)
> Created an attachment (id=89065) 
> 22x22 icons with diferent star emblem
Commited the new radio icon (bigger star) to match other new-* icons in gnome-icon-theme at similar size.
(In reply to comment #62)
> Created an attachment (id=89256) 
> Last.fm, Jamendo and Magnatune icons (v2)
Commited those icons replacing existing ones. Still not themeable (maybe I will work on it, it could be useful at least for a11y, not for "branding")
id=89262 id=89256 and id=89065 should be marked as commited
Created attachment 89322 [details]
PS please note the bad bad appearance of All/Artist/Album/Title selector in search bar :-( I'll open a bug.
Why did you remove the SVG version from SVN?:
$ svn up
This breaks the compilation:
Making all in actions
make: Entering directory `/home/alex/build/rhythmbox/data/icons/hicolor/22x22/actions'
make: *** No rule to make target `internet-radio-new.svg', needed by `all-am'. Stop.
make: Leaving directory `/home/alex/build/rhythmbox/data/icons/hicolor/22x22/actions'
make: *** [all-recursive] Error 1
make: Leaving directory `/home/alex/build/rhythmbox/data/icons/hicolor/22x22'
make: *** [all-recursive] Error 1
make: Leaving directory `/home/alex/build/rhythmbox/data/icons/hicolor'
make: *** [all-recursive] Error 1
make: Leaving directory `/home/alex/build/rhythmbox/data/icons'
make: *** [all-recursive] Error 1
make: Leaving directory `/home/alex/build/rhythmbox/data'
make: *** [all-recursive] Error 1
make: Leaving directory `/home/alex/build/rhythmbox'
make: *** [all] Error 2
(In reply to comment #73)
> Why did you remove the SVG version from SVN?:
> $ svn up
> D data/icons/hicolor/22x22/actions/internet-radio-new.svg
> U data/icons/hicolor/22x22/actions/Makefile.am
> A data/icons/hicolor/22x22/actions/internet-radio-new.xcf
> U data/icons/hicolor/22x22/actions/internet-radio-new.png
It was the source for the "old" icon, new source is internet-radio-new.xcf.
> This breaks the compilation:
Yeah, sorry, I forgot to change the Makefile.am.
Yet fixed on svn.
(In reply to comment #74)
> (In reply to comment #73)
> > Why did you remove the SVG version from SVN?:
> > $ svn up
> > D data/icons/hicolor/22x22/actions/internet-radio-new.svg
> > U data/icons/hicolor/22x22/actions/Makefile.am
> > A data/icons/hicolor/22x22/actions/internet-radio-new.xcf
> > U data/icons/hicolor/22x22/actions/internet-radio-new.png
> It was the source for the "old" icon, new source is internet-radio-new.xcf.
But the SVG files are supposed to be icons in their own right and are supposed to be the way forward ultimately for scalable icons, I thought?
Hence the presence of the hicolor/scalable directory. Shouldn't the icons be generated from the SVG source there?
If only it was that simple.. (if it was, we'd just generate the smaller sizes at runtime)
The 'scalable' icons typically look blurry and indistinct when scaled down (but they look good scaled up), so we use either custom bitmaps or simplified SVG for the smaller sizes. Compare 16x16/apps/rhythmbox.svg and scalable/apps/rhythmbox.svg in rsvg-view to see what I mean. At around 16x16, the 'scalable' version is a smudge, and at larger sizes, the 16x16 version is blocky and lacks detail.
Created attachment 89541 [details]
1st try of a new library icon
I don't really like the mimetype-icon used for the music library source (plus, I don't even understand where it is pulled from...). So I tried to come up with something better. I tried to do a shelf of CDs but this seems to be near-impossible at the required size... Then I came up with this. It's not executed very well but what do you think of the basic idea?
I think is better split this bug, using one bug report for each missing/needed icon, adding new bugs here as "depends on"
So, I've just opened:
* bug 440608 - icon for Browser button
* bug 440609 - icon for Library entry
* bug 440611 - icon for shared music entries
doh, it seems I can't edit the depends on list :-(
Created attachment 90508 [details] [review]
make magnatune and jamendo icons themeable
magnatune_circle_small.png -> plugins/magnatune/icons/hicolor/24x24/places/magnatune.png
jamendo_logo_small.png -> plugins/jamendo/icons/hicolor/24x24/places/jamendo.png
These are then installed under $pkgdatadir with the rest of our icons.
Also adds some ugly magic in the rb module to add the plugin source path to the icon search path for uninstalled builds.
I've committed that because it's probably as good as we can do.
Only left the Browser icon, it'd be reasonable to remove the Hide/Show Browser toggle button since there are no sane metaphor for this icon. Can someone cook a patch?
You want us to remove the button because you can't think of an icon to display on it? Uh.. no.
Well, sorry if I accidentally say something wrong or really bad. IMHO, based on trials of many other music software on Linux platform, I still think it's the best to remove that button. However, if you do not share my same humble opinion, my apology and I hope some artist can cook an icon for this button. CC jimmac, lapo, andreasn or hylke.
(In reply to comment #83)
> You want us to remove the button because you can't think of an icon to display
> on it? Uh.. no.
Uhm, yes. This is exactly what UI design is about. You don't know how to do it right (even after over a year!) so doing it was obviously wrong.
Simply removing things that aren't perfect is *not* what UI design is about. I believe someone was working on moving the browser toggle somewhere else (can't be bothered chasing up a bug number right now); perhaps you'd have some constructive criticism on that?
(In reply to comment #86)
> Simply removing things that aren't perfect is *not* what UI design is about. I
> believe someone was working on moving the browser toggle somewhere else (can't
> be bothered chasing up a bug number right now); perhaps you'd have some
> constructive criticism on that?
You refer to http://bugzilla.gnome.org/show_bug.cgi?id=366499 ?
IMHO, I think this option isn't something a user will/should change a lot. Therefor it's something that should be set in the preferences panes (which you only open if you want to make changes about how you use the application).
Menu-items and toolbar-buttons should be there for options/functionality a typical user changes during the usage of the program... those are the tools that make part of the program. Great examples are a play button, previous/next, or even a button to show lyrics (most ppl, I think, only want this for some songs but it makes part of the functionality).
Hiding/showing the browser is, IMO, a way of using the program. It's like choosing where to store you music library ... You chose this once according to your likings but then you probably don't want to change this behaviour very often.
If the browser is something ppl turn on when they want to quicly find a song and then turn if off again, I think it means there's something wrong with the browser itself as it shouldn't be in the way of the user who needs it to find songs.
(This in only *my* UI design interpretation)
Everyone has their own opinions on usability, I think we just should respect the GUI designer of the program. The compromising solution is to have a customize toolbar feature like EOG or Evince in which DnD toolbar icon is possible. Then everyone can customize the GUI to their own taste.
Let's design an icon for Browser and end this going-no-where discussion.
IMHO a good icon metaphor for browser is something like the one in KDE4 Dolphin "Columns" toolbar button. See 
We can't produce a good metaphor of browser concempt, so let the icon represent the UI appearance: smart, isn't it?
-- GitLab Migration Automatic Message --
This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/280.