GNOME Bugzilla – Bug 528320
Incorrect icons displayed for apps installing icons in hicolor theme
Last modified: 2009-02-04 18:30:39 UTC
Please describe the problem: Applications with mimetype icons installed the fallback "hicolor" theme are being rejected in favour of generic fallbacks which are themed in the current theme, such as text-x-preview. The GIO backend is passing a large choice of mime-types for icons into Nautilus, e.g. for this text-derrived type from gEDA: Breakpoint 2, IA__gtk_icon_theme_choose_icon (icon_theme=0x81a2890, icon_names=0x87e8ed8, size=48, flags=0) at /build/buildd/gtk+2.0-2.12.9/gtk/gtkicontheme.c:1435 1435 in /build/buildd/gtk+2.0-2.12.9/gtk/gtkicontheme.c (gdb) print icon_names[0] $33 = (const gchar *) 0x873b4b0 "application-x-geda-schematic" (gdb) print icon_names[1] $34 = (const gchar *) 0x87ed648 "gnome-mime-application-x-geda-schematic" (gdb) print icon_names[2] $35 = (const gchar *) 0x8701f60 "application-x-generic" (gdb) print icon_names[3] $36 = (const gchar *) 0x8832318 "text-x-preview" (gdb) print icon_names[4] $37 = (const gchar *) 0x8832220 "text-x-generic" (gdb) print icon_names[5] $38 = (const gchar *) 0x0 I believe the correct behaviour here should be to show the hicolor themed icon for "application-x-geda-schematic". gtk_icon_theme_choose_icon Instead, gtk_icon_theme_choose_icon() decides that a better match is: (gdb) finish Run till exit from #0 IA__gtk_icon_theme_choose_icon (icon_theme=0x81a2890, icon_names=0x87e8ed8, size=48, flags=0) at /build/buildd/gtk+2.0-2.12.9/gtk/gtkicontheme.c:1435 [Thread 0xb465db90 (LWP 1990) exited] nautilus_icon_info_lookup (icon=0x877b218, size=48) at nautilus-icon-info.c:404 404 nautilus-icon-info.c: No such file or directory. in nautilus-icon-info.c Value returned is $39 = (GtkIconInfo *) 0x83f0af0 (gdb) print ((GtkIconInfo *) 0x83f0af0)->filename $41 = (gchar *) 0x81e8ff0 "/usr/share/icons/gnome/scalable/mimetypes/text-x-preview.svg" Should nautilus infact query the icons one by one, e.g. calling: gtk_icon_theme_choose_icon() with "application-x-geda-schematic", then the others (if that first icon didn't exist)? IE... I suspect that we prefer the more specific mime-type icon from the wrong theme, than a very generic icon from the right theme. gtk_icon_theme_choose_icon () tries them all in the given order before falling back to inherited icon themes. Steps to reproduce: Open a nautilus view with files which have mime-type icons registered in a fallback theme (e.g. hicolor), but not the current theme. Actual results: generic icon from the current theme is chosen Expected results: specific mime-type icon from the fallback theme is chosen Does this happen every time? yes Other information:
Created attachment 109351 [details] [review] Proposed patch The attached patch fixes my hicolor (fallback) theme only mime-icons to display how they were with previous versions of Nautilus. It does this by asking GTK to find the most specificly named icon first, then only proceeding with the generic names if that fails.
I can confirm this problem. Nautilus displays the generic text icon for files that are correctly identified by their MIME types and for which icons are installed into /usr/share/icons/hicolor/*/mimetypes. The GTK+ file-chooser shows the correct icon for these files. Perhaps nautilus should use g_file_info_get_icon() just as the GTK+ file-chooser does?
> Perhaps nautilus should use g_file_info_get_icon() just as the GTK+ file-chooser does? Actually, we use that helper. We then construct extract the GThemedIcon's name list (i.e. g_themed_icon_get_names()), and use gtk_icon_theme_choose_icon() on it. How the lookup approaches can be roughly categorized: Strategy A: Theme consistency From a icon consistency POV it often makes sense to prefer any icons that comes from the current theme over any icons that come from a “parent theme” (i.e. hicolor). Otherwise, you'd for instance not install a MIME icon for a specific video type, and end up with a hicolor icon for the video type, instead of using a generic video type. Strategy B: Generic icons suck On the other hand, any vendor of course wants his customized icon! This demands for the contrary: Specific icons should always be preferred over generic icons. Now, we seem to have a few possibilities how to resolve the clash: A) Ignore vendors by forcing them to provide icons for any theme they want to be used in - a paradise for icon artists, but a nightmare for everyone else, including the users who have to install extra theme packages for all kinds of applications. B) Satisfy vendors by always preferring specific icons over generic ones (which is NOT in the spirit of the icon theme spec). However, non-vendor icon artists will probably bail. C) Add some flag to icons specifying whether they are supposed to be preferred even though they are not in the currently used theme D) Think very hard about the use-cases, and modify the lookup algorithm. For instance (in the spirit of proposal C): If the most specific MIME type icon in the list is present in the “hicolor” theme, use strategy B for this icon, because it's a vendor item. Otherwise (and with the rest of the icons), use strategy A. The hicolor theme is thus used as the “flag that this is a vendor icon” (from proposal C). Comments, objections?
Special casing the "hicolor" theme doesn't feel that nice, but I guess it is supposed to be the fallback. With regards mime-types, can you think of any vendor-supplied "hicolor" theme icons which would trigger if we chose option "B" above? I'm not sure the icon theme spec. even covers this case. I thought that given a specific icon name, doing "B" gives the correct lookup. The real issue here is what icon names nautilus will try first - and the prescidence given to icons which came from the user's desired theme. Lets say I make a new theme, which inherits from another - say, the "Gnome" theme. For sake of argument, lets look up the "text-html" mime icon, which my theme does not implement. Do I want that theme to fall back to the Gnome theme's "text-html" icon (and then back to hicolor if not found)... yes. What if my theme has a customised version of the "text-x-generic" icon. IMO, a file with mime-type of text/html should still prefer the same results for the "text-html" lookup, and NOT choose my theme's "text-x-generic" icon. If I wanted different, I could simply copy / symlink my generic icon to replace the text-html icon in my new theme. It would be up to me as the theme author to do that. However... I do see that method doesn't let as an icon theme author replace all text/* mimetypes with the generic icon. Without knowing the answer in advance myself.. what do KDE / other desiktops do?
Without understanding this stuff in full detail, I thought I'd give my thoughts... I think it's impossible to imagine that the default themes designed by icon artists will accommodate every possible file type for all possible Linux applications. There *have* to be some non-standard applications out there which will not make it into the icon themes. For these applications, there needs to be a way that the application authors can provide recognisable icons, for the sake of usability, because generic icons just aren't good enough (especially for ex-Windows users who aren't accustomed to looking at file extensions). For these reasons, I think there definitely needs to be a system whereby specific vendor-supplied icons can be utilised without danger of them being trumped by generic icons. I think that themed icons should trump vendor-supplied icons, though, because as the popularity of an application grows, it is possible that it might eventually gain a place in the standard icon themes. themed icon > vendor icon > generic icon The tough part would be when a themed 'text/*' icon exists (can you do that in a theme?), but a vendor 'text/x-myapp' icon exists as well. So maybe it's themed exact icon > vendor exact icon > themed wildcard icon > generic specific icon > generic wildcard icon. There's be no possibility of a vendor wildcard icon, because that's not a vendor's prerogative. These vendor icons would have to be stored in a special place, aside from the current theme-based directory structure, eg /usr/share/icons/vendor/48x48/text-x-myapp.png. Cheers JP
Why wouldn't a potential wild card such as application/x-geda-* be my porogative as a vendor (geda)?
In any case, why are we breaking the existing system? We can't expect to install vendor icons in two places. The current location already works for everything _except_ nautilus, which changed its behaviour to break this.
The reason for the current behaviour is basically for satisfying requests from the icon theme community. Lots of types have a useful "generic" version, such as image-x-generic, and when we sniff some type image/special that doesn't have a specific icon in the icon theme we want to use the generic version from the theme. Otherwise icon theme developers have no way to get a consistent theme that without having to make symlinks for all possible kind of image types. However, things get a bit problematic when the very very generic icons like text-x-generic and text-x-preview get thrown in with this too. We should probably special case at least these to so you can install custom icons for application/* mimetypes, etc.
After some talking to mclasen we decided to do the hack described above for 2.24, but for trunk to just not return the super-generic icons and instead let the apps (nautilus/file chooser) do the fallback.
Created attachment 121127 [details] [review] glib patch
Created attachment 121128 [details] [review] gvfs patch
Created attachment 121129 [details] [review] gtk patch
Created attachment 121130 [details] [review] Nautilus patch This set of patches makes this work for me. Basically we don't return the fallback icons in gio/gvfs, instead we implement it in the apps (gtk file chooser and nautilus). One problem with this is that the removal of the fallback icons is a change that apps may rely on. However, there is never any guarantee of there always being an icon of the icon always existing in the theme, so its a bogus thing to rely on that breaks in other normal cases too. I tried running with the glib/gvfs change only is not really a large problem. Missing/fallback icons are not seen in a lot of places.
commited to head and stable glib/gvfs/gtk/nautilus
I'm really happy to see this fixed. One thing I noticed scanning the patches, is that gio would provide a different generic icon fallback for files with the executable bit set: - else if (statbuf.st_mode & S_IXUSR) - type_icon = "application-x-executable"; - else - type_icon = "text-x-generic"; I didn't notice that being special cased in the new gtk / nautilus fallbacks. I've got no objection, but just wondered if that was deliberate. Once again, thankyou for fixing this bug, it is very much appreciated.
*** Bug 505507 has been marked as a duplicate of this bug. ***