After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 528320 - Incorrect icons displayed for apps installing icons in hicolor theme
Incorrect icons displayed for apps installing icons in hicolor theme
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: Views: All
2.22.x
Other All
: High critical
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 505507 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-04-15 23:31 UTC by Peter Clifton
Modified: 2009-02-04 18:30 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22


Attachments
Proposed patch (819 bytes, patch)
2008-04-16 02:21 UTC, Peter Clifton
rejected Details | Review
glib patch (806 bytes, patch)
2008-10-22 11:13 UTC, Alexander Larsson
none Details | Review
gvfs patch (1.75 KB, patch)
2008-10-22 11:14 UTC, Alexander Larsson
none Details | Review
gtk patch (584 bytes, patch)
2008-10-22 11:15 UTC, Alexander Larsson
none Details | Review
Nautilus patch (2.78 KB, patch)
2008-10-22 11:18 UTC, Alexander Larsson
none Details | Review

Description Peter Clifton 2008-04-15 23:31:47 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:
Comment 1 Peter Clifton 2008-04-16 02:21:00 UTC
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.
Comment 2 Sven Neumann 2008-09-03 18:03:30 UTC
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?
Comment 3 Christian Neumair 2008-09-03 19:28:04 UTC
> 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?
Comment 4 Peter Clifton 2008-09-07 14:10:57 UTC
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?
Comment 5 John Pye 2008-10-21 00:30:04 UTC
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
Comment 6 Peter Clifton 2008-10-21 00:36:56 UTC
Why wouldn't a potential wild card such as application/x-geda-* be my porogative as a vendor (geda)?
Comment 7 Peter Clifton 2008-10-21 00:38:07 UTC
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.
Comment 8 Alexander Larsson 2008-10-21 13:26:16 UTC
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.
Comment 9 Alexander Larsson 2008-10-21 14:49:15 UTC
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.
Comment 10 Alexander Larsson 2008-10-22 11:13:56 UTC
Created attachment 121127 [details] [review]
glib patch
Comment 11 Alexander Larsson 2008-10-22 11:14:47 UTC
Created attachment 121128 [details] [review]
gvfs patch
Comment 12 Alexander Larsson 2008-10-22 11:15:21 UTC
Created attachment 121129 [details] [review]
gtk patch
Comment 13 Alexander Larsson 2008-10-22 11:18:26 UTC
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.
Comment 14 Alexander Larsson 2008-10-23 10:08:14 UTC
commited to head and stable glib/gvfs/gtk/nautilus
Comment 15 Peter Clifton 2008-10-25 13:36:20 UTC
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.
Comment 16 Alexander Larsson 2009-02-04 18:30:39 UTC
*** Bug 505507 has been marked as a duplicate of this bug. ***