Created attachment 101729 [details] [review]
Proposed patch

For local files, this patch looks up the file type by its extensions in the registry under HKEY_CLASSES_ROOT, and uses the "Content Type" field of that extension as mime type.

thanks for the patch. some comments on the form:

+#elif G_OS_WIN32
+  char* p = strrchr(uri, '.');

wrong code style (also for the other function calls): you need a space between the function name and the parenthesis.

+  if(p != NULL)
+  {

wrong code style: if is not a function and the curly brace must be indented by two spaces

+    if(!res) recent_data.mime_type = g_strdup(GTK_RECENT_DEFAULT_MIME);

ditto as above for the g_strdup() function call, and an if on two lines make this more readable

+  }
+#endif
+#ifdef G_OS_WIN32
+  if (has_case_prefix (uri, "file:/"))

can't these two #ifdef G_OS_WIN32 be merged?

+                  if (RegQueryValueEx (key, "Content Type", ...
+                    {
+                      g_free(recent_data.mime_type);
+                    }
+                  else
+                    {
+                      success = TRUE;
+                    }

a single statement does not require curly braces

this is also a stop-gap patch: the best way to solve this is to make gtk_recent_manager_add_uri() use the GIO API for getting the content-type, assuming that the win32 backend already works.

I'm sorry for the coding style - I normally try to honor the preferred style, but I often fall back to my own without noticing.

I can change this to use gio. I guess this should then use the asynchronous version, and add the recent item when the information about the content type is available? This way gtk_recent_manager_add_item does not guarantee that the item is added immediately.

(In reply to comment #3)

> I can change this to use gio. I guess this should then use the asynchronous
> version, and add the recent item when the information about the content type is
> available? This way gtk_recent_manager_add_item does not guarantee that the
> item is added immediately.

the GtkRecentManager doesn't guarantee that new entries are added immediately; it guarantees that, if something changes in the storage, it will emit the ::changed signal. so, as far as I'm concerned, using the asynchronous version is perfectly fine.

Created attachment 102168 [details] [review]
Use gio to find mime type

This uses gio to determine the mime type in gtk_recent_manager_add_item(). Tested on Linux and Windows.

Created attachment 107985 [details] [review]
[PATCH] Use GIO to find the MIME type

updated version of the patch inside attachment 102168 [details] [review].

cleaned up the coding style, and handle the eventual errors. I also switched to using the fast mime type query - it's good enough for the add_item() case: if the user wants to be sure, then he can call g_file_query_info() and then gtk_recent_manager_add_full().

unfortunately, I cannot test it right now because I don't have a box with gvfs (need to update the jhbuild checkout); since I'm using the GIO API and comment 5 confirmed it working on two platforms, I'm going to commit this patch to trunk.

committed to trunk.

2008-04-15  Emmanuele Bassi  <ebassi@gnome.org>

	Bug 506062 – gtk_recent_manager_add_item does not detect mime
	type on Windows

	* configure.in: Depend on gio-2.0

	* gtk/gtkrecentmanager.c:
	(gtk_recent_manager_add_item_query_info_cb),
	(gtk_recent_manager_add_item): Use GIO to (asynchronously) query
	the MIME type of the passed URI.

This change seems to cause problems on my system.  For some reason, g_file_info_get_content_type always returns NULL (called from inside gtk_recent_manager_add_item_query_info_cb) independent of the file that's supposed to be added.  The following assertion occurs with the attached test program:

(recent-test.pl:10312): GLib-GIO-CRITICAL **: g_content_type_get_mime_type: assertion `type != NULL' failed
Gtk-WARNING **: Attempting to add `file:///usr/bin/perl' to the list of recently used resources, but not MIME type was defined at recent-test.pl line 11

And the file is not added to the recently-used-list.  This probably means that there's something wrong with my gio setup, but the recent chooser should just use the default MIME type in this case.  Patch attached.

Created attachment 111854 [details]
Test case

Created attachment 111855 [details] [review]
Handle content type being NULL

(In reply to comment #8)
> This change seems to cause problems on my system.  For some reason,
> g_file_info_get_content_type always returns NULL

it's probably bug 535830. Torsten, can you please try the patch attached there and confirm? otherwise, I'll apply your patch as well.

Yep, the patch in bug 535830 does seem to fix my issue as well.

(In reply to comment #12)
> Yep, the patch in bug 535830 does seem to fix my issue as well.

thanks. I've just applied that patch to trunk.