Red Hat Bugzilla – Bug 442835
make gvfs useful
Last modified: 2013-03-05 22:55:35 EST
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]
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
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
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
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
> Some things to work out:
> 1) I think using a new key in the desktop file is the way to go, propose
> 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 ?
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]
- 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
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
If you can check these RPM's
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
for details. Matthias, should we update the gio and gvfs packages in Rawhide
and/or F9 with the new patches?