GNOME Bugzilla – Bug 315841
if an SVG icon exist, it is always used for launchers even if bitmaps exist
Last modified: 2006-07-10 18:01:45 UTC
Please describe the problem: This may also be an index.theme problem with gnome-icon-theme (hicolor), but it appears that if an svg version of an icon exists, it is always used no matter is a proper bitmap for a particular size exists. Originally from bug #314758, the evolution icon comes at three sizes currently. 16x16, 24x24 and the scalable version. While launchers that only use bitmaps (16x16, 24x24, 32x32 and 48x48) use the proper size in the panel and panel menu, if a scalable version is present it is used for all sizes. I've recorded the follwoing video where you can see the trash applet using the 24x24 bitmap but the launcher does not. http://jimmac.musichall.cz/demos/misc/launchers-do-not-use-bitmaps-on-panel.avi Steps to reproduce: 1. make sure you have gnome icon theme HEAD installed 2. drag evolution launcher from the menu onto the panel 3. scale the panel (panel properties) to see other icons such as the trash applet change the icon when 24x24 is used. Evo is alsay using the SVG. Actual results: Expected results: Does this happen every time? Other information: The directories use Type=Treshold in $PREFIX/share/icons/hicolor/index.theme, but no SizeMin or SizeMax is present, maybe that's the source of the problem?
This is definitely not a panel issue: we're getting the filename for the icon at the size requested through gtk_icon_theme_lookup_icon (). So, it's either a GTK+ bug or a gnome-icon-theme issue. Note that I don't have Type=Treshold in index.theme here, so I'm reassigning to gnome-icon-theme for now.
Rodney, any idea why this happens?
No idea. I just changed a couple of minor things in index.theme.in that might be the problem. Update and let me know how it works.
See index.theme from hicolor. Here is: Directories=[...],16x16/actions,[...],scalable/actions,[...],24x24/actions,[..] If you change it, putting scalable/* at the end of the list, everything should goes fine. BTW the value for Directories key in hicolor is a mess. Someone should sort it.
Oh, I forgot: the trash panel applet grabs the proper icon 'cause it come from "gnome" icon theme (and Directories value here is well sorted), while evolution icon is in "hicolor" icon theme.
Created attachment 56329 [details] [review] The patch against default-icon-theme HEAD It seems that default-icon-theme from fd.o is not on bugzilla.fd.o. So I'm sending here the patch. And CC this bug to Alex Larsson (he is away until 09-01-06). But it's better is someone could look it. I've changed a lot of stuff, using search-and-replace, so there could be errors. PS Do you think that "Size=128" is right for scalable entries?
The size for the Directories= directive indeed have to be ordered ascending by size. I wonder where index.theme for the hicolor theme is defined though?
Created attachment 56666 [details] working hicolor index.theme
Created attachment 56667 [details] working index.theme without the stock cruft
jimmac: Why remove the stock cruft? Won't that break backwards compat?
I commited lucas patch and made a new release.
Alex: I don't believe there's anything going to stock in hicolor, that's why I simplified it. But I may be wrong.
Older gnome-icon-theme installed things in the stock dirs. If we remove them then that is a backwards incompat change.
Yea, this was about hicolor index.theme, not gnome-icon-theme.
*** Bug 315406 has been marked as a duplicate of this bug. ***
I am having problems with hicolor .9 and git 2.12.1 w/ Gnome 2.12.3. GIT Makefile.am installs many stock icons to the hicolor directory where hicolor takes it out of hicolor/index.theme but i see it under gnome/index.theme. For example stock/generic. This isn't the only one.
The only other one found so fat is stock/document. Luca, Was this missed when sorting for hicolor for this bug?
The newest version of hicolor should have those entries in its index.theme. The newest version of gnome-icon-theme, however, no longer installs icons into hicolor. Wasn't this resolved FIXED before? Why is this still open?
I think what happened was when the fix to hicolor for this bug was applied some directories were left out. I submitted a patch to the Gentoo devs to fix Hicolor .9 for use with Gnome 2.12 and XFCE. Of course Hicolor and GIT for Gnome 2.14 moved those around and works fine. The only problem might be for those still running Gnome 2.12/XFCE and hicolor? Hicolor doesn't seem to have a bug reporting mechanism. Here is the Gentoo bug if needed: http://bugs.gentoo.org/show_bug.cgi?id=122797
Hicolor bugs should be reported in http://bugs.freedesktop.org/ I'm going to mark this as fixed then.