Re: GtkFileSystemGnomeVFS

[Alexander Larsson <alexl redhat com>]

On Fri, 2004-02-13 at 00:40, Owen Taylor wrote:
> On Thu, 2004-02-12 at 07:47, Alexander Larsson wrote:
> 
> > Say gtk+ automatically looks in $libdir/gtk-2.0/2.4.0/filesystems/ for
> > filesystem implementations. Now, how do applications say they want to
> > use a gnome-vfs backend for a dialog? We clearly can't auto-use the vfs
> > backend when its installed, because a gtk-only app won't be using
> > gnome-vfs to read back the files returned from the fileselector (and
> > even in a gnome-vfs using app some uses of the fileselector might want
> > local files only). In fact, in the gtk-only case we'd prefer to not even
> > load the filesystem and its dependencies.
> 
> The local files issue is already handled in the API:
> 
>  gtk_file_chooser_set_local_only()
> 
> this defaults to TRUE, so apps have to explicitly ask to get non-local
> files.
> 
> And there is some advantage to using the gnome-vfs backend even on local
> files; in particular you get exactly matching icons and the possibility
> of displaying emblems. This is less important now that we are using
> the same mime-type sniffing code, and the same icon theme lookup, but
> not irrelevant.
> 
> There is actually one major issue here which is that if the thread
> libraries aren't in the output of `pkg-config --libs gtk-2.0` then
> applications won't be able to load up gnome-vfs successfully on certain
> platforms. (Solaris, BSD, I think.) I don't actually have a huge
> problem with always linking GTK+ apps against the thread libraries
> on these platforms, but determining what platforms need this is
> hard.
> 
> Leaving that aside, the scheme I'd imagine is a GtkSettings/XSETTINGS
> key gtk-file-chooser-backend and:
> 
>  gtk_file_chooser_set_backend (chooser, "gnome-vfs");
> 
> and look up the module by that name. We probably can actually do
> that for 2.4.0, and adjust the build flags for Solaris/BSD as necessary
> for 2.4.1.

So, the xsetting would set the default backend, and you can explicitly 
set the gnome-vfs one if you know you want to use that.

This will work. The only issue is if the app sets
gtk_file_chooser_set_local_only() to TRUE, uses the default backed, and
for some reason uses the uri based API. In this case, gnome-vfs and
GtkFileSystem better return the same file: uris for the same file. See
discussion below.

Although the I don't think the gtk_file_chooser_set_backend (chooser, 
"gnome-vfs") API works. Currently the file-system is a property of the
FileChooser and also a property of FileChooserDialog that is mirrored to
the internal FileChooser on construction time. You can't actually get at
the FileChooser for the dialog, and it would be preferable if we could
instantiate the right file-system object on FileChooser construction
time.

So. What about a new string property "file-system-backend", in both
FileChooser and FileChooserDialog, behaving much like the current
file-system type but referencing a loadable filesystem module (by name)
instead of a string, and then we add this new API:

GtkWidget *
gtk_file_chooser_dialog_new_with_backend (const gchar         *title,
                                          GtkWindow           *parent,
                                          GtkFileChooserAction action,
                                          const char          *backend,
                                          const gchar         *first_button_text,
                                          ...)

> > I think the encoding for file uris differ between gnome-vfs and glib.
> > This could cause problems. Gnome-vfs uses the raw on-disk bytes, escaped
> > as needed for the uri, while i think glib uses the escaped utf8 version
> > of the filenames. The way glib does this is problematic for gnome-vfs,
> > since you can't e.g. use such uris to rename a wrongly encoded filename.
> > Plus, it feels wrong for the uri representation of a file to depend on a
> > potentially non-global setting (G_BROKEN_FILENAMES + locale).
> 
> The file chooser makes no interpretation of URIs at all. The filename
> and URI paths are entirely independent. So, unless you are trying to
> use file:// URIs from the local backend with GNOME VFS, you aren't
> going to have any issues.

Well. You might pass the URI to another gnome-vfs using app in for
instance a text/uri-list when doing DnD.

> In terms of the what GLib does, I was really hoping that you were
> going to take ownership of that issue earlier, but I guess that never
> got communicated ... whatever is standardized needs to be written down
> on freedesktop.org somewhere, since it's every bit as much of a KDE <=>
> GNOME issue, mozilla <=> GNOME issue as a GTK+ <=> GNOME issue.

Yeah, I'm sorry I haven't done this. I've had my time filled with other
stuff. But this is pretty important, so i'll start working on it right
away, looking what gnome-vfs, kde and others do and start writing
something down.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a fast talking devious rock star plagued by the memory of his family's 
brutal murder. She's a cynical goth vampire living homeless in New York's 
sewers. They fight crime!