Re: Proposal for making the GtkFileChooser code asynchronous

[Owen Taylor <otaylor redhat com>]

On Tue, 2005-11-08 at 11:58 -0800, Brian J. Tarricone wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 11/8/2005 6:08 AM, Kristian Rietveld wrote:
> 
> > I assume that there isn't much code out there using the GtkFileSystem API.
> > In order to not have that kind of code crash and burn on a system with a newer
> > GTK+, we need to build in some kind of protection.  Does anyone have
> > suggestions on this one?
> 
> Why not keep the current API and invent a new one for async operation?
> Use gtk_file_system_async_foo() and the like, and just deprecate the
> current API.  If you install a header file to a public system location,
>  no matter what you say, it's a public interface.  If you want to change
> that API incompatibly, you're obligated to increment gtk's major
> version.  IM(NS)HO, of course.

We did two things precisely to allow this kind of change:

 - We explicitly marked the filechooser interfaces as unstable and not
   public.

   To use them, you have to define the symbol:

     GTK_FILE_SYSTEM_ENABLE_UNSUPPORTED

   I have no sympathy for someone who defines that symbol and then wants
   us to support the interfaces they used!

 - We install the modules in a versioned directory.

Because we *knew* that we weren't going to get GtkFileSystem right the
first time, and we wanted the flexibility to change it going forward.

And if you've fooled around in the FileChooser's guts, you'll also know
that it would be a really bad idea to try and support a
"GtkFileSystemEx" ... we have a hard enough time to get everything
working right doing things one way, without gobs of (likely basically
untested) compat code as well.

Regards,
					Owen