Re: Proposal for making the GtkFileChooser code asynchronous

[Sebastian Rittau <srittau jroger in-berlin de>]

On Tue, Nov 08, 2005 at 03:08:16PM +0100, Kristian Rietveld wrote:

> The last few weeks I have been working on making the GtkFileChooser code
> asynchronous.  I've been making quite a bit of progress and hope to get the
> changes in on time for GTK+ 2.10.

Great news! Here are some comments to your proposal:

> 1. Let's start out with a somewhat more general change.  We need to be able
>    to cancel currently running asynchronous operations.  For this we need
>    to have a handle on an operation, so we need to introduce a
>    GtkFileSystemHandle which would be defined the same way as GtkFileFolder --
>    each backend can provide it's own handle object.  Of course we add a
>    call which we can use to actually cancel an operation:
> 
>    gboolean gtk_file_system_cancel_operation (GtkFileSystem        *file_system,
>                                               GtkFileSystemHandle  *handle,
>                                               GError              **error);
> 
>    The gboolean return value will indicate success or failure, in the latter
>    case the error will be provided via GError.

In what way can cancelling an operation fail and why should it concern
the file chooser?

> 2. Addition of gtk_file_system_get_info(), so we are able to retrieve
>    information about a file without having to create a folder.  This is
>    useful in for example GtkPathBar. Prototypes:
> 
>    typedef void (* GtkFileSystemGetInfoCallback) (GtkFileSystem       *file_system,
>                                                   GtkFileSystemHandle *handle,
>                                                   GtkFileInfo         *file_info,
>                                                   GError              *error,
>                                                   gpointer             data);
> 
>    GtkFileSystemHandle *gtk_file_system_get_info (GtkFileSystem                 *file_system,
>                                                   const GtkFilePath             *path,
>                                                   GtkFileInfoType                types,
>                                                   GtkFileSystemGetInfoCallback   callback,
>                                                   gpointer                       data,
>                                                   GError                       **error);
> 
> 
>    If the return value of gtk_file_system_get_info() is NULL, and the error
>    argument is non-NULL a description of the error will be provided in there.
>    Only errors which occurred before the asynchronous information acquisition
>    process started will be reported this way.  All other errors will be
>    reported via the callback.

If this was a public, often-used API, I would recomment against
returning an error here and instead use the callback for all error
handling. This means that you need only one error handler, instead of
two (that would probably duplicate some functionality). But since there
will probably only one user of this API and multiple providers, doing it
like this is probably better, since it is easier to implement.

> I would say that it is clear that we are going to break the API completely
> here, and also not continuing to support the old API.  Third party code
> should not notice anything of these changes, except for third party code
> using the GtkFileSystem API.  Since the GtkFileSystem API is not supported,
> 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?

As others have suggested, please make sure that the old plugins are not
loaded to prevent crashes. Older GNOME versions should not crash with
newer gtk+ versions. I think just renaming the search path is an okay
solution.

 - Sebastian