Bug 442835 - make gvfs useful
Summary: make gvfs useful
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: glib2
Version: rawhide
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-04-17 05:42 UTC by David Zeuthen
Modified: 2013-03-06 03:55 UTC (History)
2 users (show)

Fixed In Version: glib2-2.16.3-4.fc9
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-04-18 00:30:28 UTC
Type: ---
Embargoed:


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

Description David Zeuthen 2008-04-17 05:42:10 UTC
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 05:42:10 UTC
Created attachment 302703 [details]
initial version

Comment 2 David Zeuthen 2008-04-17 05:42:42 UTC
Ugh, wrong component.

Comment 3 David Zeuthen 2008-04-17 06:00:36 UTC
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 13:10:24 UTC
<sarcastic> or maybe use modifiers: %gu, %ku  </sarcastic>

Comment 5 Matthias Clasen 2008-04-17 18:43:52 UTC
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 20:44:52 UTC
(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 20:45:52 UTC
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 20:51:12 UTC
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 20:52:48 UTC
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 20:59:06 UTC
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 21:05:13 UTC
(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 22:39:07 UTC
> 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-18 00:29:59 UTC
(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-30 00:18:43 UTC
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.