Re: GtkFileSystemGnomeVFS

[Owen Taylor <otaylor redhat com>]

On Thu, 2004-02-12 at 07:47, Alexander Larsson wrote:
> On Wed, 2004-02-11 at 17:38, Federico Mena Quintero wrote:
> > 
> > How do we install GtkFileSystemGnomeVFS?  In theory, you should get it
> > for free if your app calls gnome_vfs_init().  Should we have
> > 
> > 1. gtk_file_chooser_set_default_file_system_type (GType type)
> > 
> > 2. GType _gtk_magic_variable_with_file_system_type;
> > 
> > 3. gnome_vfs_file_chooser_dialog_new ()
> 
> I was under the impression that i would just build a gtk+ module and
> install it somewhere, and all apps would be able to get gnome-vfs
> support in the fileselector. Isn't this the case? If every app has to
> explicitly link to libgnomevfsgtkfilesystem and call functions from it
> to create vfs-using, then this code should be in libgnomeui (like I
> initially argued[1]).

I think putting things into libgnomeui would be a mistake in any case;
this would force apps that just want gnome-vfs + gtk+ to get the 
whole libgnomeui mess, which we seem to be trying to get rid of.

But I hope we can find a solution that doesn't require explicit
linking to another library. 

> 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, we need to set up a gtk-query-fsmodules thing that generates
> $sysconfdir/gtk-2.0/gtk.fsmodules, so we can detect filesystem modules
> without loading them. Given this, how do apps use this? One way is to
> introduce a 'file-system-name' string property for GtkFileChooser so we
> can reference the fs type without referencing the
> gtk_file_system_gnome_vfs_get_type symbol. If loading the vfs module
> fails we fall back to the unix one, and the app won't notice the
> difference (except it only gets file: uris).

Avoiding another query-modules is pretty important to me. I want to 
completely redo how the ones we have already work - see:

 http://bugzilla.gnome.org/show_bug.cgi?id=129540

You don't need a query-modules setup to load a module by name; e.g.,
we don't have a query-modules system for theme engines, we just look
for a shared object with the right name.

> 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.

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.

Regards,
						Owen