Lots of desktop files use '%u' to specify that they want a URI rather than an old skool POSIX file path. Unfortunately %u is way too optimistic as - there are many different URI schemes (one for each VFS system) and there is little or no standardization (e.g. ssh:// for gvfs, fish:// for KDE) - Many applications are overly optimistic and set %u even though they'll never ever support anything but files - lots of GNOME apps still use gnome-vfs and as such don't support newer URI's from gio (gphoto2, cdda). And even for the ones they do support, for example ssh://, it may mean asking for credentials again The current situation in current Rawhide is clearly suboptimal: right now you can't even open text files (gedit) or view images (eog) from URI's not supported by gnome-vfs. This includes archive://, gphoto2:// and cdda://. Haven't tested with obex-ftp://. This is somewhat unacceptable. Fortunately gvfs supports a FUSE mount at ~/.gvfs. In fact, if a desktop file uses %f instead of %u, then a path into ~/.gvfs will be used instead. The application will Just Work(tm). I will attach a very simple patch that introduces a new environment variable GIO_URI_WHITELIST. If this environment variable is not set, nothing will change. However, if it is set, then gio will parse this variable as a white list of applications that are known to user libgio. In this case, launching desktop files where the binary is in that list, a gio URI is passed just as we do today. Otherwise the URI is translate into a fuse POSIX file name. This patch is obviously not ready for upstream. And it most likely need some extra work / review to be ready for Fedora 9. However, the patch does magically make GNOME in Fedora 9 work a lot more smoothly with a lot of applications. For example, with this patch one can now view text and image files (via gedit and eog) on gphoto2://, archive:// and cdda:// mounts. (For upstreaming, one path is to propose a new key into the desktop entry spec that identifies what kind of URI scheme a given application is compatible with.) Thanks for considering.
Created attachment 302703 [details] initial version
Ugh, wrong component.
In the unlikely event Alex is reading bug mail he should have a chance to reject the idea ;-). Either way, the patch was less than an hours work so I don't feel too bad if either of you rejects this idea. But do keep an open pragmatic mind about this. Also a clarification.. with > (For upstreaming, one path is to propose a new key into the desktop entry spec > that identifies what kind of URI scheme a given application is compatible with.) ^^^^^^^^^^ I of course meant s/URI scheme/VFS system/. So e.g. totem would have VFSSystem=gio set and we'd parse that in gio/gdesktopappinfo.c and act accordingly.
<sarcastic> or maybe use modifiers: %gu, %ku </sarcastic>
I assume we should probably take something like this approach for F9. Some things to work out: 1) I think using a new key in the desktop file is the way to go, propose X-GNOME-Vfs-System=gio X-GNOME-Vfs-System=kio etc 2) move the g_return_if_fail up front in the function 3) how does this interact with the must_support_uris parameter of g_app_info_get_default_for_type ? Do we only return an app if it supports not only %U, but also gio ?
(In reply to comment #5) > I assume we should probably take something like this approach for F9. Sounds good. We can always back it out if it causes problems. I'll attach a revised patch. > Some things to work out: > > 1) I think using a new key in the desktop file is the way to go, propose > X-GNOME-Vfs-System=gio > X-GNOME-Vfs-System=kio > etc Done. > 2) move the g_return_if_fail up front in the function Done. > 3) how does this interact with the must_support_uris parameter of > g_app_info_get_default_for_type ? Do we only return an app if it supports not > only %U, but also gio ? I think we return it regardless of it supporting gio or not. I mean, this patch makes every app support uri's through through FUSE. Sounds sensible?
Created attachment 302805 [details] 2nd try Other changes - Always pass http uri's - If the fuse daemon isn't always just pass the URI
An interesting question is if we should prefix the passed POSIX paths with file://. I don't know. I don't think so. Notably this breaks /usr/libexec/gvfsd-archive but that is a bug in that program; it should use the _from_commandline variant of GFile constructors. Either way setting X-Gnome-Vfs-System=gio in /usr/share/applications/mount-archive.desktop fixes this problem...
Here's a short list of desktop files where we want to use X-Gnome-Vfs-System=gio totem mount-archive nautilus Possibly others.
I'd like to get rid of the environment variable Why do you fall back from force_file_uri_macro to expand_macro_single, can expand_macro_single ever return NULL ?
(In reply to comment #10) > I'd like to get rid of the environment variable Oh, the thinking was it may come in handy for debugging etc. I mean, to turn this feature off. I can remove it if you want. > Why do you fall back from force_file_uri_macro to expand_macro_single, can > expand_macro_single ever return NULL ? Yes, if there's no fuse mount (you may not have gvfs-fuse installed).
> Oh, the thinking was it may come in handy for debugging etc. I mean, to turn > this feature off. I can remove it if you want. Yeah, I kinda dislike random undocumented env vars to turn stuff off Also, when you commit this, please file an upstream bug with the patch. Thanks
(In reply to comment #12) > Yeah, I kinda dislike random undocumented env vars to turn stuff off I've nuked that. > Also, when you commit this, please file an upstream bug with the patch. Thanks http://bugzilla.gnome.org/show_bug.cgi?id=528670 If you can check these RPM's http://koji.fedoraproject.org/koji/taskinfo?taskID=571619 http://koji.fedoraproject.org/koji/taskinfo?taskID=571637 http://koji.fedoraproject.org/koji/taskinfo?taskID=571655 and verify for me it works as intended then I'll ask rel-eng to tag these for F9 and send some mail to fedora-desktop-list about this. I haven't touched totem yet; will talk to Bastien. Thanks.
OK, I've updated my patch with a superior approach that doesn't involve any desktop keys, see http://bugzilla.gnome.org/show_bug.cgi?id=528670 http://bugzilla.gnome.org/show_bug.cgi?id=530654 for details. Matthias, should we update the gio and gvfs packages in Rawhide and/or F9 with the new patches?