GNOME Bugzilla – Bug 629231
ICO MIME type "regression"
Last modified: 2012-06-22 10:15:47 UTC
Created attachment 169921 [details] Add the "image/vnd.microsoft.icon" MIME type to the ICO loader The FreeDesktop.org shared MIME database now identifies .ico files as "image/vnd.microsoft.icon", and since gdk-pixbuf doesn't list that as a MIME type, libgnome-desktop no longer wants to thumbnail .ico files, and (at least) Nautilus thus displays no thumbnail for .ico files. The attached 1 line patch adds "image/vnd.microsoft.icon" to the MIME types listed by the gdk-pixbuf ICO loader and fixes the problem. On http://mail.gnome.org/archives/gtk-devel-list/2010-September/msg00134.html it was suggested that this fix is wrong or incomplete, because the calling code should be able to handle MIME type aliases if the main MIME type changes. But: * Both Nautilus (libnautilus-private/nautilus-thumbnails.c: nautilus_can_thumbnail_internally() -> pixbuf_can_load_type() -> get_types_table()) AND gnome-desktop (libgnome-desktop/gnome-desktop-thumbnail.c: gnome_desktop_thumbnail_factory_can_thumbnail() -> mimetype_supported_by_gdk_pixbuf()) do plain g_hash_table_lookup() calls to find the MIME type using an exact match; there is no g_content_type_equals(). * If the intention in gdk-pixbuf was to have the caller find all MIME aliases on the calling side, why return more than 1 MIME type? It looks to me like the intention was to provide all MIME types, main and aliases, so the caller could do a strcmp(). * Even if gdk-pixbuf isn't supposed to provide aliases, it currently only provides aliases - the new main type "image/vnd.microsoft.icon" is not even listed.
it should be enough to replace if (g_ascii_strcasecmp (type, mime_type) == 0) { in gdk-pixbuf-io.c:805 with g_content_type_equals Can you test if that fixes your problem ?
Remember that content types are not mimetypes on windows.
g_content_type_equals() does not fix the problem: In Nautilus, the MIME type must first pass the nautilus_can_thumbnail() test (libnautilus-private/nautilus-file.c function nautilus_file_get_icon) before an attempt to thumbnail it is even made. nautilus_can_thumbnail() delegates to gnome_desktop_thumbnail_factory_can_thumbnail(), which fails for reasons explained in the initial bug comment; to recap, it calls mimetype_supported_by_gdk_pixbuf(), which does this: formats = gdk_pixbuf_get_formats (); list = formats; while (list) { mime_types = gdk_pixbuf_format_get_mime_types (format); for (i = 0; mime_types[i] != NULL; i++) g_hash_table_insert (formats_hash, (gpointer) g_strdup (mime_types[i]), GUINT_TO_POINTER (1)); list = list->next; } if (g_hash_table_lookup (formats_hash, mime_type)) return TRUE; return FALSE; The exact g_hash_table_lookup() comparison does an exact match, which is what causes the problem. But again, Nautilus does something similar to libgnome-desktop for internal thumbnailing. It's likely other applications also do exact matches. Should we be fixing all clients of gdk-pixbuf, or just adding a new MIME type to gdk-pixbuf itself?
We should be fixing the clients to use the GIO api properly, certainly.
I've changed gdk-pixbuf to use g_content_type_equals. Moving this bug to gdk-pixbuf to fix that mime type hash.
Created attachment 170305 [details] [review] untested patch
Here is an untested patch to make gnome_desktop_thumbnail use g_content_type_equals when checking if a mimetype is supported.
Comment on attachment 170305 [details] [review] untested patch Can someone test this? If it works fine, please commit to master, and ask the release team for freeze break approval. (Note: the patch is mixing tabs and spaces)
The libgnome-desktop patch works, thank you.
Committed to master and gnome-2-32
*** Bug 545133 has been marked as a duplicate of this bug. ***