Incorrect icons displayed for mimetypes installed in hicolor theme only

Attached is a debdiff which fixes the icons to how they were with Gutsy. It does this by asking GTK to find the most specificly named icon first, then only proceeding with the generic names if that files.

Thanks for working on it.

I've been in contact with upstream, the problem is understood, but I don't think a decision has been reached on how best to fix it.

The concern is that in some cases, slightly more generic icons from the user's selected theme _could_ be better than a very specific icon from some fallback. (E.g. for media icons).

Since the Nautilus regression doesn't look like it will be fixed quickly, from the libgeda point of view there is one thing we could do to repair the user experience for some Ubuntu users, perhaps for hardy-updates.

We could add symlinks or copies of the hicolor icons we ship into the default Ubuntu theme (perhaps the GNOME theme too?), which will at least give the nice user experience for users who haven't customised their themes very far from default.

I'm pretty gutted these icons are missing due to the large amount of work which went into getting this all ready for Hardy in the first place, and I'll do what I can to help fix this in the long term.

Would the nautilus packagers entertain a patch which tries finding an icon for the _first_ mime type returned by GIO, then asking GTK to choose if that can't be found? This should have the desired effect, but retain the "this theme first" preference for the more generic names returned the most specific mime-type.

I discussed with upstream on IRC yesterday too and I'm not decided yet on what would be the best way to solve that. Agreeing with upstream rather than having a distribution specific patch would be nice. That's something which can be fixed in hardy-updates

Could someone point out just one situation where it would be better to see the more generic icon instead of a more specific fall back icon?

When your theme is very different from Tango, e.g. uses a specific color palette or is highly stylized, the specific fallback icons (which are usually in Tango style) look horrible.

Firstly, what is the primary and most important reason to have icons at all? Options:
1. To look pretty?
2. To quickly convey meaningful information about a file's contents?

I'd much rather have informative, ugly icons than pretty, meaningless ones.

Secondly, reductio ad absurbam: suppose I install an icon theme which contains only one icon, a blank square, set with a mimetype association to all/allfiles. What would the correct behaviour be? Krzysztof seems to be arguing that every file icon should be replaced by that one, irrespective of actual mimetype.

Finally, let's consider practicalities. It takes time to create icons, and artistic talent. Many projects are too small to attract much in the way of artist attention to create a full set of icons themselves for every distribution's pet icon theme, while at the same time being too small for the distributions to create icon sets on their behalf. Are they therefore doomed *never* to have their (fairly well drawn) icons appear, just because they can't provide icons for pet_icon_theme_of_the_month?

@Peter: I agree that the current situation isn't great because hicolor mimetype icons in fact never get shown. The proper thing to do would probably be to display the custom mimetype icons when the default theme is used and use the generic fallbacks when a custom theme is in use.

Regarding your reductio ad absurdum argument the correct behavior would depend on whether we want to keep style or convey information. If we want to keep the theme consistent the correct thing to do would be to display all files as this icon - this may well be the author's intent. However if we intend to convey information we could use the specific hicolor theme icons. I think this decision would be best left to the theme author, so the solution is to add a flag to the index.theme file, let's call it "InheritsMimeTypes", that would determine whether to use hicolor mime icons if they are more specific. If your theme is reasonably tango-like then you set it to true. If it's completely different like Gartoon Redux or Black&White, you set it to false so the style is consistent.

@Krzysztof (Chris) Kosiński: "I think this decision would be best left to the theme author, so the solution is to add a flag to the index.theme file, let's call it "InheritsMimeTypes", that would determine whether to use hicolor mime icons if they are more specific."

So the poor users don't get a say? What a shame.

Clearly, in your scenario, it is the users choice. She can choose to use a theme that sucks or one that doesn't.

@ Peter Brett: The user can't choose and pick what icons he/she likes anyway except by creating a custom theme, so not exposing this setting for existing themes is OK.

@ bug maintainers: please undupe bug #217997, it is not a duplicate of this bug (see comment in that bug).

Addendum to the above: The default Gnome theme would have InheritsMimeTypes set to true, so users would get the custom application-supplied icons by default but if they choose a theme that is stylistically different from Tango the author of that theme wouldn't have to create icons for all imaginable mimetypes to keep stylistic consistency.

the bug has been fixed upstream now

Was never a bug in libgeda really, so marking as invalid

--- RantMode On ---
What is happening to you people? Does anyone actually understand what this bug is about? This is NOT bug #278113, or any related bugs. Please read and comprehend both descriptions before changing the status.
--- RantMode Off ---

Probably a more detailed explanation is necessary. File icons are determined by the MIME type of the file. There are three places where Gnome looks for those icons: 1. the current theme, 2. inherited themes, in the order in which they are specified in the index.theme file, 3. hicolor theme. Additionally, the MIME database from freedesktop.org defines some additional icon names like script-x-generic and font-x-generic that are not assigned to any specific mimetypes, but are intended as fallbacks when a more specific icon is not available.

For example, let's assume that the mimetype "application/x-m4" (M4 macro) says in the MIME database that its generic icon is "script-x-generic". There are two custom themes on the system, let's say Adamantium and Bionic. Adamantium has the icon "script-x-generic", but does not have "application-x-m4". Bionic has them both. There is a specialized M$ macro editor installed too, and it puts its own Tango-style icon "application-x-m4" in the hicolor theme.

Bug #278113 was about Bionic displaying "script-x-generic" even though it has "application-x-m4" (obvious bug). This bug is about a GEDA maintainer not satisfied with Adamantium displaying "script-x-generic" instead of "application-x-m4" from hicolor (correct, but not ideal behaviour).

This bug cannot be fixed without a new way to provide additional information from the theme designer: if the theme is Tango compliant, it should display the Tango icon for "application-x-m4" from hicolor. If it's completely different from Tango, it should use its own fallback icon "script-x-generic". As such, this is definitely not "fix committed" and not specifically related to Nautilus, but rather to GLib icon theme lookup.

Sorry, I obviously meant "M4 macro editor" instead of "M$ macro editor"... :)

Wait, it was me who was confused by the invalid duplicate link... forget what I said (or maybe don't forget the explanation). I think the solution the upstream chose (screw theme artists and introduce inconsistencies between applications) is completely wrong, but the bug is nonetheless "fixed" for the reporter.

Sorry, I'm tired today and this subject has a lot of subtleties... They just removed their own ultra-generic "text-x-generic" fallback that had nothing to do with the fallbacks defined in the shared MIME database, so this fix seems OK.

the issue is fixed in jaunty now