GNOME Bugzilla – Bug 395830
Wrong named icon lookup when requested size matches two size dirs
Last modified: 2011-02-04 16:10:57 UTC
Due to the switch to Tango size (22x22 pixels) in gnome-icon-theme and the use of legacy size in UI (24x24 pixels), currently GNOME Desktop is using in different places 22x22 icons scaled up to 24x24 pixels even when the 24x24 icons are available. This odd behavior was reported and discussed on gnome theme list (see http://mail.gnome.org/archives/gnome-themes-list/2006-December/msg00027.html ). The main issue is in the Icon Lookup algorithm from Icon Theme Spec, as explained in http://mail.gnome.org/archives/gnome-themes-list/2006-December/msg00031.html and confirmed by Alex Larsson in http://mail.gnome.org/archives/gnome-themes-list/2007-January/msg00001.html I don't know if Alex have yet updated the Icon Theme Spec to reflect this, but IMHO GTK+ could start to provide a fix :-)
Created attachment 80219 [details] [review] a patch Here is an untested patch that might do the right thing: if the icon theme spec calculation yields a distance of 0, keep going for threshold directories, and compare based on the actual distance.
Created attachment 80221 [details] [review] working patch Using continue in a while loop is a bad idea... This patch has been (minimally) tested, and seems to give the desired results: testicontheme lookup hicolor gpm-inhibit 19 --> picks scalable testicontheme lookup hicolor gpm-inhibit 20 --> picks 22 testicontheme lookup hicolor gpm-inhibit 21 --> picks 22 testicontheme lookup hicolor gpm-inhibit 22 --> picks 22 testicontheme lookup hicolor gpm-inhibit 23 --> picks 22 testicontheme lookup hicolor gpm-inhibit 24 --> picks 24 testicontheme lookup hicolor gpm-inhibit 25 --> picks 24 testicontheme lookup hicolor gpm-inhibit 26 --> picks 24 testicontheme lookup hicolor gpm-inhibit 27 --> picks scalable
Patch applied on my jhbuild sandbox, I'm recompiling. Meanwhile, two notes: * while it's stuff for another bug report, the Icon Naming Spec defines the usage of '-' character to create "levels of specificity in icon names". Example: "media-optical" named icon is more generic then "media-optical-dvd"; if the current theme provides only the first and an application needs the second, you should use the first as fallback. This is described here http://standards.freedesktop.org/icon-naming-spec/latest/ar01s03.html and maybe GTK* should implement too * isn't glib a better place for implementation of icon lookup? While, of course, you need a graphical UI to show icons, developers could need to define and lookup then on non-GTK+ stuff. See the Alex complain about no icon support in gnome-vfs. Quoting him email: "This means that all users above the vfs must implement it themselves (e.g. in nautilus and in the file selector). Each implementation have its own bugs, maintainance load and risk for different behaviour. It also means that vfs backends cannot supply their own icons, something which might be very useful for e.g. a network share based on some new fancy web service"[2], Moving icon lookup il glib will allow non-UI libraries to define and use named icons. [1] http://mail.gnome.org/archives/gnome-vfs-list/2006-September/msg00023.html
(In reply to comment #2) > Created an attachment (id=80221) [edit] > working patch > > Using continue in a while loop is a bad idea... > This patch has been (minimally) tested, and seems to give > the desired results: Works fine on my jhbuild sandbox (gtk+ 2.10 branch)
2007-01-14 Matthias Clasen <mclasen@redhat.com> * gtk/gtkicontheme.c (theme_lookup_icon): When finding a matching non-scalable dir, keep going and look for a closer match. (#395830, Luca Ferretti)
Oh, and please file a separate bug for supporting generic fallbacks a la the icon naming spec. That will require new api
(In reply to comment #6) > Oh, and please file a separate bug for supporting generic fallbacks a la the > icon naming spec. That will require new api > Done, see #396901 What about icon lookup in glib? Is it simple stupid? Maybe g*vfs can simply define macros like #define G_VFS_MEDIA_OPTICAL_CD "media-optical-cd" and let applications use them.
You'd have to move gdk-pixbuf to glib first...very unlikely to happen.