GNOME Bugzilla – Bug 92346
Window icons don't respect icon theme
Last modified: 2011-02-04 16:17:01 UTC
The icons in the window list, the workspace switcher and in the popup window that appears when you cycle between windows, desktops or panels do not respect the current icon theme (as being drafted on freedesktop.org). Thus in a high or low contrast theme, you still get the default coloured icons showing up in those places.
Fun for the whole family - fixing this means adding support for it to the platform, then changing all the apps. Can't be done on the metacity level.
Icon theme support is now in GTK+, so it's just a matter of adding gtk_window_set_icon_name() gtk_window_set_default_icon_name() (There may be some issues in the icon theme handling code if we want to set the correct icon list and provide the icon at all sizes at which it exists in the icon theme... it's not clear what size we would look it up at with the current icon theme API)
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
*** Bug 120487 has been marked as a duplicate of this bug. ***
*** Bug 122280 has been marked as a duplicate of this bug. ***
*** Bug 121761 has been marked as a duplicate of this bug. ***
*** Bug 120266 has been marked as a duplicate of this bug. ***
*** Bug 114887 has been marked as a duplicate of this bug. ***
*** Bug 98489 has been marked as a duplicate of this bug. ***
Can we get clarification on where the fix for this needs to be, and whether we need new API or not? Thanks - if we need API changes, time is very tight indeed.
I think Owen already clarified the necessary API additions here: gtk_window_set_icon_name() gtk_window_set_default_icon_name() Then you have to go around and change all uses of set_icon() and set_default_icon() by the _name() variants.
Here is a preliminary patch, not tested beyond compilation. Things which are still missing are: - test it - handle screen changes - when default icon name is set, must connect to changed signal for icon theme on all screens - icon sizes should probably be handled more intelligently
Created attachment 21914 [details] [review] patch
*** Bug 128059 has been marked as a duplicate of this bug. ***
marking 'normal' instead of 'enhancement' - since theme-compliance isn't considered a 'new feature', it's expected of icons in GNOME nowadays (I hope!). Note that there are 7 (!) duplicates of this bug... can we get the patch reviewed for 2.4, _please_ ? thanks. It would substantially enhance GNOME 2.6's theme compliance if we could get this in.
Bill, have you tested the patch ? That and working on the known deficiencies is the most effective way to get this closer to GNOME 2.6 I'll ask owen whether he sees issues beyond the ones listed above...
Although this would be really nice to have, I don't think we are close enough on this to do it for GNOME-2.4. Issues with the patch: * I'm really not happy with the approach of loading the icon at a bunch of "random" sizes and setting them in the list. Putting a scaled icon into the icon list is very likely to result in the final icon being displayed to the user being double scaled, and hence extremely fuzzy. The set of icons set as the list should be all or a subset of the sizes that the icon is actually available at. This may require GtkIconTheme API enhancements. * The general approach here doesn't work right for things like RSVG icons, or when we need an icon at anything other than one of the specificied sizes. I'd like to see a WM spec enhancement so that GTK+ could advertise the icon name as well, so that if the window manager / icon list, whatever understood it, it could go directly from that. * The way I'd do the notification for screen changes is to hook up to GtkIconTheme::changed in realize_icon, this gives you notification on all relevant screens and largely covers over the per-window / default differences. (Adding this wouldn't do us much good for GNOME-2.6 considering how close we to code freeze for GNOME...)
Created attachment 29009 [details] [review] a new patch Here is the patch again, I've added api to obtain the list of available icon sizes from the theme. This doesn't handle scalable icons at all yet. But it seems to work nicely in my quick tests.
In gtk_window_set_icon_name(), etc, when calling update_themed_icon() I'd probably just pass in NULL for icon_theme ... I don't see a point in getting the theme and then not using it. I think by policy we do do the work so that gtk_window_set_icon_name (window, gtk_window_get_icon_name (window)) works - i.e., add a if (name == info->icon_name) return; Would be nice to expand the docs for gtk_window_set_icon_name() a bit. Maybe Sets the icon for the window from a named themed icon. See the docs for #GtkIconTheme for more details. And then ref set_icon_name() in get_icon_name(). The current docs are especially bad because "icon name" means something else in the ICCCM. (A short name for a window to display in the icon) gtk_window_set_default_icon_name() is missing docs. For icons with only a scalable image, it would probably be best to set them at at least a fixed size (say 48) rather than not set them at all. Other than those, the patch looks good to me.
Committed, with fixes for the mentioned issues