Re: GtkFileChooser API work

[Owen Taylor <otaylor redhat com>]

On Tue, 2003-09-02 at 15:04, Alexander Larsson wrote:
> On Tue, 2003-09-02 at 19:54, Havoc Pennington wrote:
> > On Tue, Sep 02, 2003 at 12:49:08PM -0500, Federico Mena Quintero wrote: 
> > > Plain GTK+ apps would be using the GtkFileSystemUnix implementation. 
> > > Right now it only returns "/" in list_roots, but I guess we could steal
> > > some code from (say) the Midnight Commander to read the information from
> > > mtab et al.  MC is GPL, though...
> > 
> > Not plain GTK apps but plain GTK desktops I would think (how I was
> > hoping it would work is that we have the gnome-vfs backend in a
> > loadable module that all GTK apps pick up).
> 
> How can that work? The non-gnome-vfs using apps wouldn't be able to
> handle the gnome-vfs uri they get from the fileselector.

GtkFileChooser has:

/**
 * gtk_file_chooser_set_local_only:
 * @chooser: a #GtkFileChooser
 * @local_only: %TRUE if only local files can be selected
 *
 * Sets whether only local files can be selected in the
 * file selector. If @local_only is %TRUE (the default),
 * then the selected file are files are guaranteed to be
 * accessible through the operating systems native file
 * file system and therefore the application only
 * needs to worry about the filename functions in
 * #GtkFileChooser, like gtk_file_chooser_get_filename(),
 * rather than the URI functions like
 * gtk_file_chooser_get_uri(),
 **/

Even apps that link to GnomeVFS may need this... it's not clear to
me that apps that apps that want to use GnomeVFS for one
thing will suddenly handle *all* file operations through GnomeVFS.

Another problem is linking to -pthread; on some systems, it won't
work to take a module that links to GnomeVFS and uses threads and
link it into a non-threaded program.

The only real fix I can of for that is to have GTK+ pull in -pthread
on such systems.

Linking the main app to -pthread may also be needed if we fix
accessibility not to require gnome_program_init().

Regards,
						Owen