GNOME Bugzilla – Bug 528670
Always pass file:/// uri's in GAppLaunchContext
Last modified: 2009-10-30 14:30:06 UTC
This bug was originally filed in the Red Hat bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=442835 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 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://. This is not ideal. 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). Will attach a patch that will pass a POSIX FUSE path instead of an URI for %u and %U if both of the following conditions are met - the desktop file doesn't have a key X-Gnome-Vfs-System with the value gio - FUSE is available and mounted at e.g. $HOME/.gvfs As such, the thinking is that apps that use gio will have X-Gnome-Vfs-System=gio in their desktop files. With this patch using things like gedit, eog and mplayer (and virtually any other non-gio app) from the Nautilus Just Works(tm). It's pretty cool actually. It's probably worth raising the larger problem at xdg-list and settle on a key similar in spirit to X-Gnome-Vfs-System. FWIW, we're going to try and ship this patch for Fedora 9.
Created attachment 109462 [details] [review] Proposed patch
Can you raise on xdg-list and quickly agree on a non-GNOME-specific key?
(In reply to comment #2) > Can you raise on xdg-list and quickly agree on a non-GNOME-specific key? It might be better to first agree whether we want this in gio in the first place. FWIW, I *think* we do as mclasen and I decided to try this for F9. We'll see.
If you do keep the GNOME-specific key, it should be "X-GNOME-", not "X-Gnome-", to be consistent with other GNOME-specific keys.
A better is this - Always pass FUSE paths even to gio apps (if the FUSE daemon is available). That way we won't need a X-Gnome-Vfs-System desktop key. - Have the fuse daemon set an xattr on every mount with the gio URI, e.g. the directory "$HOME/.gvfs/gphoto2 mount on usb:001,042" would have an xattr called gio:uri with the value gphoto2://[usb:001,042]/ - All GFile constructors would check, for file:/// URI's, if the path is into the FUSE mount, e.g. begins with $HOME/.gvfs - If so, lookup the gio:uri xattr and convert the uri to the use this. E.g. this piece of code GFile *f; f = g_file_new_for_command_line_arg ( "/home/davidz/.gvfs/gphoto2 mount on usb:001,042/foo.txt" g_print ("uri=%s\n", g_file_get_uri (f)); would print uri=gphoto2://[usb:001,042]/foo.txt Ditto for g_file_new_from_path(), g_file_new_from_commandline_arg() and g_file_parse_name(). - The CPU overhead in checking the given uri / path / command line arg points into the fuse mount is virtually nil compared to the overhead of constructing the GFile object itself - This does a minimal amount of IO [1], e.g. looking up the xattr on the fuse, only if the passed uri actually points into the FUSE mount - this is OK since properly written apps would only every encounter FUSE paths when taking incoming data from other apps (e.g. command line arguments). - Since we convert early and in every GFile constructor the app would quickly end up using real URI's instead of FUSE paths. E.g. this piece of code doing IO would very rarely run; basically only when the app starts and process the uri's given on the command line. I will look into writing patches for this. [1] : alexl's stance is that we cannot do any IO at all
Some comments: Not all uris are availible via fuse, even if fuse is active Only "visible" mounts are shown in fuse, which means things like network: computer: etc don't work. Also, http doesn't work. Any implementation needs to actually try to convert the arguments to local paths to make sure it works before falling back. You can't always roundtrip a uri through a GFile and expect things to always works. Many uris are not for "files" and the uri parser in GIO just won't understand them. Take for instance mailto: uris or callto: uris. In many cases you really want the actual uri in the app, not the fuse path, passing a fuse path to something like wget or mozilla just doesn't make any sense as they generally do more with the uri than just open a file.
Hey Alex, Thanks for taking some time to comment on this. I appreciate it. (In reply to comment #6) > Some comments: > > Not all uris are availible via fuse, even if fuse is active > > Only "visible" mounts are shown in fuse, which means things > like network: computer: etc don't work. Also, http doesn't work. Any > implementation needs to actually try to convert the arguments to local paths to > make sure it works before falling back. > > You can't always roundtrip a uri through a GFile and expect things > to always works. Many uris are not for "files" and the uri parser in GIO > just won't understand them. Take for instance mailto: uris or callto: uris. In the case of 1) either FUSE not available; or 2) mount not available via FUSE; then g_file_get_path() will return NULL. In that case the patch in comment 1 actually falls back and tries just to pass the proper URI just like we do today. (In fact, the check for http in that patch is superfluous) Which I think addresses your concerns, right? > In many cases you really want the actual uri in the app, not the fuse path, > passing a fuse path to something like wget or mozilla just doesn't make any > sense as they generally do more with the uri than just open a file. Right, that's what I proposed in comment 5 by tweaking the GFile constructors to map URI's of the form file://$HOME/.gvfs back to URI's by looking at base URI from xattrs on the directories of the root of the fuse mount. Do you see any problems with this approach? Anyway, I'll try to whip up gvfs and gio patches based on comment 5 tonight. I wanted to do that last week, but I got carried away with other things.
Note that it also causes problems with: - applications that don't use GIO but support URIs (say, a web browser, or a movie player) - applications that map back between specific URIs and devices (sound-juicer, totem and rhythmbox need to be able to map back between cdda://sr0/ and /dev/sr0, but might not use GIO). I'd rather applications be encouraged to use gio directly. Even for an application that doesn't fully use gio, patching it to give a try opening the local FUSE path is 3 lines of code.
(In reply to comment #8) > Note that it also causes problems with: > - applications that don't use GIO but support URIs (say, a web browser, or a > movie player) Do you have any concrete examples here? It's not like mailto:// or http:// or asf:// paths will be replaced by a FUSE path. They can't, because there's no mount. So the URI will be passed. > - applications that map back between specific URIs and devices (sound-juicer, > totem and rhythmbox need to be able to map back between cdda://sr0/ and > /dev/sr0, but might not use GIO). FWIW, cdda:// in gvfs will be renamed to cdafs://, see bug 527159. We should try hard to make sure there is no overlap between the gstreamer and the gvfs URI schemes to avoid to these kind of problems. > I'd rather applications be encouraged to use gio directly. (Except when it comes to using the gvfs cdda backend?) > Even for an > application that doesn't fully use gio, patching it to give a try opening the > local FUSE path is 3 lines of code. Speaking of three, or maybe four, lines of code; I think, for s-j, totem, rhythmbox it's just as easy to do GFile *f = g_file_new_for_commandline_arg (argv[0]); char *uri = g_file_get_uri (f); if (g_str_has_prefix (uri, "cdafs://")) { /* compute your gstreamer uri here */ } if you really insist on making these apps bypass gvfs for playback / extracting audio from Audio CD's. Here's the thing: lots of apps will never ever move to gio, e.g. mplayer, KDE apps and so forth. And these apps will _continue_ to use the ill-defined %u parameter in their desktop files. This results in breakage en masse when launching files from Nautilus. The problem is that %u simply doesn't work when you have more than one VFS system. IMO it was a mistake to introduce it in the desktop entry spec.
Created attachment 110138 [details] [review] Updated patch Here's an updated patch
For the required gvfs patch to fixup the GFile constructors to map back (actually there was even a TODO in the source to do this), see bug 530654.
(In reply to comment #8) > Note that it also causes problems with: > - applications that don't use GIO but support URIs (say, a web browser, or a > movie player) > There is a huge problem with mapping "URIs" between different applications. I am very sure that gvfs, gstreamer and your web browser have very different ideas about what a URI is[1]. The only thing they unfortunately agree on is the syntax, which means it's impossible to tell different VFSs apart. I think the first step to get back to sanity would be changing GIO to not report ftp:// or http:// URLS but instead use gvfs://<mount>/<path> syntax. That would at least avoid confusion about what an ftp:// URL is. Plus, it would be exceptionally easy to s.gvfs://./home/me/.gvfs. or vice versa to convert to local paths. And this is the point where you could just use local paths anyway and avoid lots of pain if you made the FUSE daemon mandatory. [1]: Example: GVfs paths are by design absolute and they start at a designated root directory. These are two assumptions that don't hold for the RFC specifying the ftp:// URI scheme. [2] So it is not possible by design to map your browser's idea of ftp to GVfs. I'm not sure what epiphany ftp://user@example.com should display? [2]: ftp://ftp.isi.edu/in-notes/rfc1738.txt - paragraph 3.2
*** Bug 551575 has been marked as a duplicate of this bug. ***
Am sad to see this interesting discussion has stalled. It's certainly a nontrivial task, but a partial solution that works adequately for 80% of cases [1] would certainly be an improvement over confusing 'does nothing' operation which currently reigns. [1] I'm thinking mainly of smb:// or sftp:// URIs - likely candidates for remote volumes within Nautilus on which you'd want a local app to act.
We're getting closer - Alex committed the patch in bug 530654. See bug 530654 comment 6 for some thoughts on how to resolve this bug without having to include hints in the desktop file.
Fixing up summary. Also, the patch in comment 10 pretty much should work even though it may have bitrotted.
So, if we were to put this in glib 2.18.x, how badly will it break a) with a gvfs that doesn't have the fix in bug 530654 ? and b) will it break apps that expect real urls unless they do what David described in comment #9 ? GFile *f = g_file_new_for_commandline_arg (argv[0]); char *uri = g_file_get_uri (f); if (g_str_has_prefix (uri, "cdafs://")) { /* compute your gstreamer uri here */ }
(In reply to comment #17) > So, if we were to put this in glib 2.18.x, how badly will it break > > a) with a gvfs that doesn't have the fix in bug 530654 ? Apps, even with using gio, will do IO through the fuse daemon; it's what we're doing in F9 (try opening a movie through a sftp url), seems to work fine. There's a performance penalty though. > b) will it break apps that expect real urls unless they do what David described > in comment #9 ? > > GFile *f = g_file_new_for_commandline_arg (argv[0]); > char *uri = g_file_get_uri (f); > if (g_str_has_prefix (uri, "cdafs://")) { > /* compute your gstreamer uri here */ > } For the cdda:// example it means totem will get a file:/// fuse uri; it will playback the file just fine. Though certain metadata might be missing that totem would have been able to obtain using the gstreamer cdda plug-in. Anyway, I still maintain that apps that break in this case (expecting a special uri to be passed to them and breaking when getting a file:/// fuse uri) are broken anyway. They're relying on non-specified [1] magic uri formats. Actually I'm not sure we want this for glib 2.18 / gvfs in 2.24; there's always interesting distro-specific stuff that might show up. So here's what I'd suggest going forward - apply the patch in comment 10 to trunk; then, assuming we get a new glib release for GNOME 2.26, then GNOME 2.26 will be fine and all this will work. Any bugs (which will typically be application bugs) that might show up can also get fixed during the 2.25 cycle. - tell vendors they need to patch gio (with the patch in comment 10) and gvfs (with the patch from bug 530654) if they want this functionality. The fact that a similar approach has caused no problems in Fedora 9 might help convince people it's fine. Specifically for Fedora 10, I would recommend that (just a continuation from what we've been doing in Fedora 9). Thoughts? [1] : non-specified in the sense that, for a given uri scheme foo, there's a) no specification for the foo uri format; and b) no specification of how to share authentication / session / cookies. See bug 530654 comment 8 paragraphs 2 + 3 for more details.
I'm not sure what negative impact applying this to stable could have. There's a gut-feeling of 'this is changing too much behaviour for stable' but thinking it through rationally, it's not going to be breaking anything. Far from it, it will be transparently enhancing the scope of GNOME for a negligible penalty (some apps will show 'file://' URIs instead of proto://' ones) definitely +1 on "mplayer et al are broken already by implementing their own proto://" - the scope of launching mplayer from Nautilus is surely negligible anyway.
GNOME needs a policy about stable releases and what kind of stuff is allowed to be put into them. I have the same gut feeling about breaking stuff and would think it should only be applied to 2.26. Or would any of you ship this in a RHEL update?
any chance we can commit the patch in comment 10 on trunk?
Yes, committing this to trunk is fine. Can you also add a paragraph (and a "Notes about GLib 2.20" section) to README.in with some of the hints from comment #9 ?
Committed with some docs/notes added http://svn.gnome.org/viewvc/glib/trunk/README.in?r1=6947&r2=7566&view=patch http://svn.gnome.org/viewvc/glib/trunk/gio/gappinfo.c?r1=7554&r2=7566&view=patch 2008-10-01 David Zeuthen <davidz@redhat.com> * gdesktopappinfo.c (expand_macro): If possible, always pass FUSE file:// URIs (such as '/home/davidz/.gvfs/sftp on foo/file.avi') instead of the gio URI (such as sftp://foo/file.avi) when using g_app_info_launch() and friends. With a sufficiently recent gvfs, apps using gio+gvfs will map the FUSE file:// URI back to the gio URI (and thus bypass the fuse daemon) thanks the patch from bug #530654. Since Nautilus is an user of g_app_info_launch() it means that non-gio POSIX apps, such as mplayer, will Just Work(tm) when launced via the file manager. Win. Fixes bug #528670. * gappinfo.c: Add some notes about the FUSE POSIX URI <-> GIO URI mapping to the description of GAppInfo. 2008-10-01 David Zeuthen <davidz@redhat.com> * README.in: Add "Notes about glib 2.20" section detailing the ramifications of the patch from bug #528670.
(In reply to comment #5) - All GFile constructors would check, for file:/// URI's, if the path is into the FUSE mount, e.g. begins with $HOME/.gvfs I think this condition is a little too strict because a file may be on a FUSE mount even if its path does *not* begin with $HOME/.gvfs . This situation occurs any time a symbolic link that points to a file under $HOME/.gvfs is created somewhere else in the system (e.g. /tmp). I therefore think we should look up the gio:uri xattr even if the file path does not start with $HOME/.gvfs. If the xattr does not exist, that simply tells us this is not a FUSE file. Checking for the xattr is a more robust method than checking for the $HOME/.gvfs prefix. I have a similar concern about symbolic links as described in commnt #11 of bug #530654.
Does this address drag-and-drop from nautilus into other apps, or is its scope restricted to launching files with their associated applications?
This has nothing to do with DND
In the interests of uniformity, should DND not be covered in the scope of this bug? i.e. Why should double-clicking an icon invoke different behaviour from dragging the same icon into a target application's already-open window?
Just a little re-open for this. These patches have bitten me on the backside a little. Opening a Nautilus window to "/home/gdh/.gvfs" shows one directory - "mp3 on eddie" If I double click on that (so I can drag/drop mp3's into an Audacious playlist) Nautilus cleverly opens "smb://eddie/mp3/" instead.. I'm now completely unable to open any POSIX path starting with /home/gdh/.gvfs in Nautilus! If I've manually browsed to a hidden directory like ~/.gvfs, shouldn't that be an indication that I know what I'm doing?
(In reply to comment #28) > Just a little re-open for this. > > These patches have bitten me on the backside a little. > > Opening a Nautilus window to "/home/gdh/.gvfs" shows one directory - "mp3 on > eddie" > > If I double click on that (so I can drag/drop mp3's into an Audacious playlist) > Nautilus cleverly opens "smb://eddie/mp3/" instead.. I'm now completely unable > to open any POSIX path starting with /home/gdh/.gvfs in Nautilus! > > If I've manually browsed to a hidden directory like ~/.gvfs, shouldn't that be > an indication that I know what I'm doing? Sounds more to me like Nautilus drag/drop code is doing it wrong - it really should be passing the path using g_file_get_path() just like GDesktopAppInfo and friends is doing... that way the FUSE path "/home/gdh/.gvfs/mp3 on eddie/mp3/foo.txt" will be passed when you are dragging the file foo.txt from file manager window showing the location "smb://eddie/mp3"....
Hi David, Yep, I agree completely.. see comments #25, #26, #27 in this bug. I was really pleased at the time that the current implementation went live. I believe it's now a great time (yes, speaking as a non coder) to complete this work for full compatibility and a uniform user experience. In the interim I've changed the .desktop file for audacious so that a double-click will '-e' enqueue rather than open the file directly. I don't expect most users should have to resort to such hacks. Plus, audacious is only a single use case...
Just out of curiosity, is there any chance this POSIX-compliant D-n-D support will go in to 2.28? I notice there's a month until the hard freeze - is there substantial work required to achieve this functionality? (again, I am a non-coder) :)
(In reply to comment #31) > Just out of curiosity, is there any chance this POSIX-compliant D-n-D support > will go in to 2.28? I notice there's a month until the hard freeze - is there > substantial work required to achieve this functionality? (again, I am a > non-coder) I would start by filing a bug against Nautilus, referencing this bug...
Cool, hence bug 592125 - wasn't sure of the correct procedure :)