What's your distribution? Normally, the command used to open a given MIME type is obtained from the MIME cache, which is generated by parsing .desktop files present in /usr/share/applications/. You should have a look at the file for OpenOffice Writer there and see what the Exec line is; you may also have a custom one in ~/.local/share/applications/, and personal preferences in ~/.local/share/mime/.

What is strange is that we use GIO, so any bug here should also affect Nautilus and other GNOME tools...

Distro is uptodate f10 (clean install, not upgrade, though home directory may have old cruft in it.) 

Like I said works fine from gnome-open and can also confirm it works fine from nautilus.

louie@towel ~/.local/share]$ grep -Ri odt *
louie@towel ~/.local/share]$ grep -Ri soffice *

returns nothing. Similarly no mention of soffice in /usr/share/applications/.

So not sure where this is coming from; haven't seen with any other filetypes either though admittedly I haven't tried very many.

the document display uses GtkRecentManager, and it looks like ~/.recently-used.xbel explicitly includes both document and application. Presumably that file is listed as having been opened by soffice in ~/.recently-used.xbel?

Does the file show up in the recent files list in the old panel? And if so, does it try to open it with soffice too?

You're right that soffice is in the recently-used.xbel; no idea how that would have snuck in there. Despite that, opens as expected (in ooo) from the recently used list in the old panel.

I have exec="'soffice'" in my .recently-used.xbel as well, it's presumably how the openoffice integration with the recently used list writes it. Which implies that nothing else is paying any attention to the exec="" - everything is just getting opened with the default association,. Checking the panel code would probably be worthwhile though,

(It might be weird to have two files with the same type open with different programs depending on what you did last?)

(In reply to comment #5)
> Checking the panel code would probably be worthwhile though,

	recent_info = gtk_recent_chooser_get_current_item (chooser);
	uri = gtk_recent_info_get_uri (recent_info);
	mime_type = gtk_recent_info_get_mime_type (recent_info);
	//FIXME gtk_recent_info_get_application_info() could be useful

	if (show_uri (uri, mime_type, screen, &error) != TRUE) {

So yeah, it ignores the app in the GtkRecentInfo. We should probably update the GtkRecentManager docs accordingly... (and remove the FIXME in gnome-panel).

and file a bug against OOo anyway

Ah, this explains why gnome-shell opens downloaded audio/video/document files with epiphany rather than an app that can actually handle them.  Perhaps we could check the file's mime type against the types listed in the app info?

Maybe the best to do is what gnome-panel does: opening it without considering which app was used last time. This way we stay consistent with Nautilus, and our behavior is more predictable.

I'm attempting to add the checks I mentioned, without much success..

We have two things we could use to match the GtkRecentInfo against a GAppInfo in order to figure out if the app can actually open the file: the app name (not ID), which is localised, and the executable path, which seems like it could be a bit flaky for apps with launcher scripts and the like.

Another less interesting problem I'm having is that Gio.app_info_get_all_for_type() returns a list full of undefined objects.  Or maybe I'm doing something wrong..

Created attachment 133764 [details] [review]
Use default application for the mime type to open the document instead of using appExec for the last application that was used to open the document info.

Should I try using the appExec for the last application for the document info if the application associated with the given mime type was not found?

Patch looks good, except that the comment:

            // The point of passing an app launch context to launch_uris() is mostly to get
             // startup notification and associated benefits like the app appearing
             // on the right desktop; but it doesn't really work for now because we aren't
             // reading the application's desktop file, and thus don't find the
             // StartupNotify=true in it. So, despite passing the app launch context,
             // no startup notification occurs.

is leftover, and doesn't apply when you call app_info_get_default_for_type(). However, a fallback to appExec sounds reasonable to me, and the comment cold be adapted to that case, since it would still apply there.

Created attachment 134048 [details] [review]
New patch for opening documents

Add the fallback on appExec in case a default application for the document's mime type was not found. Move the comment about not getting the startup notifications.

Looks good

Filed https://bugzilla.redhat.com/show_bug.cgi?id=499474 about Open Office writing 'soffice %u' as an exec value in ~/.recently-used.xbel.