GNOME Bugzilla – Bug 561494
FileChooser network browsing and authentication support
Last modified: 2009-01-21 21:13:40 UTC
Currently, GtkFileChooser lacks support for browsing network://, smb:// and possibly any other filesystems, which don't have their own visible mounts. Also, we want file chooser to correctly handle cases where login is required in order to get list of shares on the server. Steps to reproduce: 1. In Nautilus (or anywhere else) add a bookmark pointing to network://, a samba server (without specifying share!), etc. 2. Spawn a FileChooser and click the bookmark 3. An error stating the location is already mounted will show up and will prevent you to access the resource - or - Contents will show up but network servers or shares are treated as files
Created attachment 123026 [details] [review] gtk-filechooser-network-browsing.patch Proposed patch, treating G_FILE_TYPE_SHORTCUT and G_FILE_TYPE_MOUNTABLE as directories with the support of following URIs to their target destinations. The G_IO_ERROR_ALREADY_MOUNTED is silently dropped as these types of resources don't have volume objects when mounted and will always be listed as unmounted. The full functionality of this feature depends on the patch posted in bug 545980, which will take care of mounting (and authentication) during browsing.
Shouldn't the function be called _gtk_file_info_consider_as_directory ?
Also, I'm not 100% sure about the handling of win32 shortcuts. Are those always pointing to directories ?
Other than that, the patch seems to work nicely. Two things I noticed are: 1) you get file list entries that behave like directories, but with icons that do not really scream "i'm a directory". Not sure we can do much about that. Maybe there is some way to indicate directoryness other than the icon ? 2) for such long-running network mounting operations where we show the wait cursor for a noticable amount of time, it would imo be nice if Esc would cancel the operation, not close the file chooser. Btw, tml points at bug 163544 in relation to (lack of) win32 shortcut handling.
Note that currently there is no code in gio that would create GFileInfos of type G_FILE_TYPE_SHORTCUT.
In that case, I think we should leave shortcuts out of this right now.
I've dropped the shortcut handling and renamed the function. * gtk/gtkfilesystem.[hc] (_gtk_file_info_consider_as_directory): Privately export this method. It classifies directories and mountables the same. * gtk/gtkfilesystem.c (enclosing_volume_mount_cb): Silently drop G_IO_ERROR_ALREADY_MOUNTED error for gvfs backends without visible mounts. * gtk/gtkfilesystemmodel.c: * gtk/gtkfilechooserbutton.c: * gtk/gtkfilechooserentry.c: * gtk/gtkfilechooserdefault.c: Use the new function instead of direct checks for G_FILE_TYPE_DIRECTORY throughout.
I've filed bug 564435 and bug 564436 for the issues mentioned in comment 4
Created attachment 124722 [details] [review] gtk-filechooser-gio-shortcut.patch Thanks for the commit and sorry for the late reply. However G_FILE_TYPE_SHORTCUT is heavily used in network and smb-browse backends and is required for proper functionality. Updated patch against trunk attached. At the moment there's no code in GIO utilizing G_FILE_TYPE_SHORTCUT, we should keep this in mind when implementing Win32 shortcut handling.
Ok, I didn't know that smb actually produces shortcuts. Please commit this then, to both trunk and gtk-2-14
Committed as rev. 21906 (trunk) and 21905 (gtk-2-14). 2008-12-15 Tomas Bzatek <tbzatek@redhat.com> * gtk/gtkfilechooserdefault.c: (list_row_activated): * gtk/gtkfilesystem.c: (_gtk_file_info_consider_as_directory): Mask G_FILE_TYPE_SHORTCUT as a directory (#561494)
So if detection of shortcuts (.lnk files) is added to gio on Win32, should they then *not* be identified as G_FILE_TYPE_SHORTCUTs, if that now must mean something that points to a folder? Should shortcuts instead on Windows be identified as G_FILE_TYPE_SYMBOLIC_LINK? Fun;)