Generic mimetype icons override specific icons in the same theme

Thanks for the bug report. This particular bug has already been reported, but feel free to report any other bugs you find. The issue has been discussed before hardy and there is a bug open but not sure about the exact number

bug #217997 is the nautilus bug about those

No, this is a completely different bug. Bug #217997 is about mimetype icons in the hicolor theme. This one is about generic mimetype icons from the theme overriding specific icons in the SAME theme! I.e. I have both application-x-rar.svg and package-x-generic.svg in the SAME theme (not in hicolor), but for files that have the mimetype application/x-rar, the icon for package-x-generic,svg is shown instead of application-x-rar.svg.

I have commented on the linked bug before I reported this one so I am well aware of it, and I'm still certain this is a different bug, and it was certainly not present in Hardy, because the icons were showing up correctly before the upgrade to Intrepid Beta.

Addendum: Audio and some text icons don't seem affected by this. audio-mpeg, audio-x-wav, audio-x-ms-wma, text-x-csrc, text-x-c++src, text-x-chdr show up correctly.

In general, mimetypes that have the generic-icon element set in the MIME database (/usr/share/mime/packages) always use the generic icon, instead of using it only if there is no specific icon in the current theme.

This is most probably a bug in update-mime-database 0.51, which doesn't write the /usr/share/mime/icons file.

This is a compound bug, and to fix it either Glib or update-mime-database need to be modified. Here is the relevant snippet from glib2.0-2.18.1/gio/gcontenttype.c, function g_content_type_get_icon:

  if (xdg_mimetype_icon)
    icon_names[n++] = xdg_mimetype_icon;

  icon_names[n++] = mimetype_icon;
  icon_names[n++] = legacy_mimetype_icon;
  icon_names[n++] = generic_mimetype_icon;

The problem is, xdg_mimetype_icon is NULL only if there is no generic icon defined. It looks for icon names in /usr/share/mime/icons, but this file is empty when generated using current update-mime-database (this might not be a bug - maybe the icons file is a legacy feature, I don't know), so it always contains the generic icon name. mimetype_icon is the specific icon name created by replacing slashes with hyphens in the mimetype name. legacy_mimetype_icon is the gnome-mime- variant. generic_mimetype_icon is the first part of the mimetype before slash (e.g. application) with -x-generic appended.

The correct order is therefore:

  icon_names[n++] = mimetype_icon;
  icon_names[n++] = legacy_mimetype_icon;
  if (xdg_mimetype_icon)
    icon_names[n++] = xdg_mimetype_icon;
  icon_names[n++] = generic_mimetype_icon;

because mimetype_icon and legacy_mimetype_icon are the most specific names. However, if the /usr/share/mime/icons file is supposed contain icon names for all mimetypes, this is a bug in update-mime-database, and the aforementioned Glib code is correct.

I posted a patch to shared-mime-info (to be precise the update-mime-database utility) which fixes this problem, see bug #279911

This bug should be reopened asap, it's definitely NOT the same problem of bug #217997. I'm seeing it as well, with a custom-made icon installed in the gnome icon theme (NOT hicolor) which used to work with glib <=2.16.

I posted the correct fix for this under bug #280867. This is a GLib problem.