GNOME Bugzilla – Bug 348994
Puts 22x22 icons into hicolor/24x24/apps and uses downscaled scalable icons for tray icon
Last modified: 2007-04-02 22:36:30 UTC
Please describe the problem: The original Tango icon set includes the sizes 16x16, 22x2, 32x32 and scalable SVGs. To generate the 24x24 icons that are commonly used in GNOME they are enlarged with the command "convert -border 1x1 -bordercolor Transparent $icon-old $icon-new". This adds a build dependency for ImageMagick, however. G-p-m skips this step and directly places the icons from the 22x22 folder in the source tarball into the 24x24 directory below the hicolor icon theme. Additionally the notification area icon looks fuzzy because the scalable icons are used instead of the PNG files. If the scalable SVGs are deleted from hicolor/scalable/apps the tray icon looks crisp. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
I doesn't look fuzzy to me, even when I go up to 32 size panel size. What is the proper way to fix this? Depend on imagemagik and install the 24px as well, or check the 24x24 icons into cvs? Thanks.
2006-07-29 Richard Hughes <richard@hughsie.com> * configure.in: * data/icons/22x22/Makefile.am: Generate the 24x24 icons by using imagemagick to add a 1px border around the installed icons. This makes gnome generally happier, and should fix the fuzzyness for some people. Fixes #348994 Can you please check that this is fixed with the latest CVS. Many thanks.
Wouldn't it be better to not use imagemagick? A simple C program using gdk-pixbuf would work just as well, and not add any dependency (I'll happily write it if you want).
Bastien, Jon already complained about this. :-) I've checked the 24x24 icons into CVS and removed the imagemagick code as this made the build over complicated for little actual gain. Thanks for the offer tho. Richard.
Created attachment 71310 [details] Fuzzy tray icon I wonder whether my setup is borked in any way but I still get a fuzzy tray icon. All sizes are present and g-p-m chooses downsample the svg instead of using the approriate icon size. Feel free to reclose if you find this not reproducible. NB: I purged g-p-m and rebuilt the icon cache to make sure it didn’t interfere. Platform is Ubuntu Edgy.
What version gtk you use?
I also see this bug. gtk is version 2.10.2-0ubuntu1
Oh, and btw, a crisp icon (maybe 24x24) is selected when the panel size is increased from the standard 24 to 26.
Does this happen with other applications?
(In reply to comment #7) > I also see this bug. gtk is version 2.10.2-0ubuntu1 Dito here. (In reply to comment #9) > Does this happen with other applications? No, not at all.
Richard: I've been trying to understand this and I'm starting to think that the new gtk_status_icon is the culprit here. The following code is a little program that creates an status icon with a gpm icon. On my 24 pixels panel it displays the svg scaled down just like gpm is doing. If I increase the panel size to 26 it will change just like the gpm one does to a properly sized icon (btw if you try it you'll notice a bug in the icons, I'll comment about it on bug #352416), then at panel size 34 they will change again to the svg but then I guess they look OK. ----- #include <gtk/gtk.h> int main (int argc, char **argv) { GtkStatusIcon *si; gtk_init (&argc, &argv); si = gtk_status_icon_new_from_icon_name ("gpm-keyboard-030"); gtk_status_icon_set_visible (si, TRUE); g_printf ("%i\n", gtk_status_icon_get_size (si)); gtk_main (); return 0; } ----- I tried calling gtk_status_icon_get_size() but that one always return 200 pixels regardeless of the panel size at the moment the program is launched which I think is bogus but then I don't know much about gtk. That's all for now.
I've nailed this one and the good news is that it's not a bug in gnome-power-manager :-) Ok, the problem (in ubuntu at least) is in the hicolor-icon-theme package version 0.9-0ubuntu4 which ships an index.theme like this: ... [22x22/apps] Size=22 Context=Applications Type=Fixed <-- the culprit ... changing to Type=Threshold (like all the other entries around there actually) and regenerating the theme cache solved the problem for me.
FYI I filled this on malone: https://launchpad.net/distros/ubuntu/+source/hicolor-icon-theme/+bug/58287
Further investigations have puzzled me a bit. It seems that gnome-icon-theme, Tango and others really do use Type=Fixed on all sizes except for scalable and still their icons behave OK (tested with my little test app). So, hicolor uses threshold all over the place and ubuntu changed that line to Fixed, but it still should work as Tango and other also use fixed for these sizes. It turns out that the difference is that the other themes use MinSize=32 for the scalable icons and hicolor uses MinSize=1, so changing this to 32 in the scalable/apps entry and returning to the Fixed Type in the 22x22/apps yelds correct results too. Now, what is the correct fix? Revert the ubuntu change or fix hicolor's MinSize for scalables upstream? Should I file a bug in freedesktop's bugzilla?
Good catch, BTW. I don’t know much about it but I’d say the latter, since, why should a scalable icon be used at lower sizes than 32x32? Tango and g-i-t even proceeded to have all icons prepared as PNGs in 32x32 because the scalables still suffer from scaling loss and artifacts at that size.
Guys, thanks for looking into this, appreciated.
Any ideas guys?
This looks fixed in Ubuntu Edgy. Please re-open if you have more details.
I'm not reopenig the bug since it seems an Ubuntu issue, but it is still present in the upcoming Feisty (updated to 3rd of April, 2007). I tested also Rui's sample program with an icon from NetworkManager and it looks sharp in notification area, as it should be (so I think we can exclude a GtkStatusIcon bug).
Luca, have you checked out comment 12?
Richard, tested rigth now :) Yes, this fixes the problem here too. Now I wonder why my index.theme was broken if Ubuntu package was fixed... Anyway thanks.