GNOME Bugzilla – Bug 144704
Move gnome-open.c to libgnomeui and make it call gnome_authentication_manager_init()
Last modified: 2009-05-03 20:24:04 UTC
Opening sftp:// urls fails using gnome-open and other programs based on the gnome_vfs_url_show. Probably and easy fix is to make nautilus the default handler for these.
Having url-handlers for full uris has problems. It causes nautilus to not use its normal machinery to open a directory. Instead it just launches the app with the uri as argument. Not a very efficient way to open a folder. So, this probably shouldn't be done.
Does it affect the normal behaviour (apparently not, I've just set epiphany has ftp:// handler and the ftp still works fine in nautilus) ? If it only happens with gnome-open I don't really get the problem. We have the choice between no support for gnome-open and a "not very efficient way" ... the not efficient way seems to work fine here.
With the file types and properties capplet gone, is there still a way to set the ftp:// handler apart from manually editing the gconf database? Setting version 2.9/2.10, since it still occurs there.
Alex: But the internal mechanism you talk about isn't known to gnome-open, of course; except if you add an additional parameter which tells nautilus to use its internal directory loading mechanism. For now I think it's perfectly OK to associate nautilus with ftp/sftp URIs.
Created attachment 46123 [details] [review] Proposed patch (against HEAD). After applying this patch, users will at least be able to gnome-open their sftp/ftp folders. If one passes a file, nautilus yells that this isn't a folder. IMHO it should try to launch the application associated with this MIME type and only bail if none exists/could be launched, telling the user that there is no application installed suitable to display this URI. But then again, maybe we shouldn't shift that much functionality into nautilus and have some internal meachanism to check the mime type first.
Christian: i'd suggest making the command 'nautilus --browser' instead of 'nautilus' by default, since spatial is a little more confusing on remote machines (IMHO). But yeah, otherwise... the choice here seems clearly between 'inefficient' and 'totally completely broken', so surely we should go with inefficient? Given that this means that by default ftp support in epiphany is broken (AFAICT), marking up.
I prefer spatial everywhere (often using nautilus and sftp) and it's certainly better to respect the user's stated preference.
Also note that if we don't fix bug 309127, this patch might not be that helpful after all, since people trying to open sftp://user:foo@mymachine/foobar/bar.tbz2 won't succeed.
Also discussed here : https://launchpad.net/products/gnome-vfs/+bug/8306
What is the current status of this bug report? Just asking because the problem described has struck me in service-discovery-applet recently (https://launchpad.net/distros/ubuntu/+source/service-discovery-applet/+bug/42393). Does the proposed fix work? Or is there another possible fix? Thanks, Oliver
Calling gnome_vfs_get_file_info with a URI with login credentials supplied works perfectly, even for directory locations. Something somewhere up the chain in gnome-open needs to detect the login failure and invoke the "Authentication Required" dialogue that is apparently in libgnomeui. I don't know exactly the best way of doing this, but hopefully someone will be inspired a bit. An unfortunate side-effect would be that to fork the application, you would need to pass a URI complete with username and password as a process launch argument. Pretty bad security hole. Perhaps we should start passing tokens around or something.
We used to have a handler for ftp: similar to the one you propose here, and it generated all sorts of bugs, so that was removed. Seem better to fix the bug. Seems like gnome-open needs to call gnome_authentication_manager_init().
Also, with the proposed workaround, won't all sftp:// urls will be opened in nautilus, including for instance a text file you click on in a sftp directory.
Fixing the component.
Should the call to gnome_authentication_manager_init() be placed before or after gnome_program_init()?
After.
but doesn't that also make libgnome depend on libgnomeui? maybe gnome-open should be moved over to the ui part of the libs?
Yeah, thats probably required.
I see there's a suggestion to move it to gnome-vfs on the libgnome/ui must die page. How do you feel about that?
Gnome-vfs doesn't use Gtk+ though, so that would change the build requirements. Furthermore, I'm working on gvfs to replace gnome-vfs and would like to avoid adding stuff to a to-be-deprecated module.
I'll move it to libgnomeui then and add the call to gnome_authentication_manager_init()
*** Bug 394887 has been marked as a duplicate of this bug. ***
Will do this when we branch after 2.18.x
Now gnome-open was ported to GIO at least.
gnome-open has been replaced by gvfs-open.