Bug 442835 - make gvfs useful
make gvfs useful
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: glib2 (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-17 01:42 EDT by David Zeuthen
Modified: 2013-03-05 22:55 EST (History)
2 users (show)

See Also:
Fixed In Version: glib2-2.16.3-4.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-17 20:30:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
initial version (1.39 KB, patch)
2008-04-17 01:42 EDT, David Zeuthen
no flags Details | Diff
2nd try (3.46 KB, patch)
2008-04-17 16:45 EDT, David Zeuthen
no flags Details | Diff

  None (edit)
Description David Zeuthen 2008-04-17 01:42:10 EDT
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.
Comment 1 David Zeuthen 2008-04-17 01:42:10 EDT
Created attachment 302703 [details]
initial version
Comment 2 David Zeuthen 2008-04-17 01:42:42 EDT
Ugh, wrong component.
Comment 3 David Zeuthen 2008-04-17 02:00:36 EDT
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.
Comment 4 Matthias Clasen 2008-04-17 09:10:24 EDT
<sarcastic> or maybe use modifiers: %gu, %ku  </sarcastic>
Comment 5 Matthias Clasen 2008-04-17 14:43:52 EDT
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 ?

Comment 6 David Zeuthen 2008-04-17 16:44:52 EDT
(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?
Comment 7 David Zeuthen 2008-04-17 16:45:52 EDT
Created attachment 302805 [details]
2nd try

Other changes
 - Always pass http uri's
 - If the fuse daemon isn't always just pass the URI
Comment 8 David Zeuthen 2008-04-17 16:51:12 EDT
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...
Comment 9 David Zeuthen 2008-04-17 16:52:48 EDT
Here's a short list of desktop files where we want to use X-Gnome-Vfs-System=gio

 totem
 mount-archive
 nautilus

Possibly others.
Comment 10 Matthias Clasen 2008-04-17 16:59:06 EDT
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 ?
Comment 11 David Zeuthen 2008-04-17 17:05:13 EDT
(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).
Comment 12 Matthias Clasen 2008-04-17 18:39:07 EDT
> 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
Comment 13 David Zeuthen 2008-04-17 20:29:59 EDT
(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.
Comment 14 David Zeuthen 2008-04-29 20:18:43 EDT
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?

Note You need to log in before you can comment on or make changes to this bug.