Comment 6 for bug 278113

Revision history for this message
Krzysztof Kosinski (tweenk) wrote :

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.