Re: Proposal for making the GtkFileChooser code asynchronous

[Tim Janik <timj imendio com>]

On Tue, 22 Nov 2005, Kristian Rietveld wrote:

> On Fri, Nov 11, 2005 at 11:06:17AM +0100, Tim Janik wrote:
> > >  gboolean gtk_file_system_cancel_operation (GtkFileSystem
> > >  *file_system,
> > >                                             GtkFileSystemHandle  *handle,
> > >                                             GError              **error);
> >
> > hm, since with GtkFileSystemHandle you already have an extra
> > object/structure
> > per operation, couldn't you simply store the GtkFileSystem*file_system
> > pointer
> > in it, so this can become (plus cancellation-cant-fail):
> >
> >   void     gtk_file_system_cancel_operation (GtkFileSystemHandle  *handle);
> >
> > and, if the handles are really only in place for asyncronous operations,
> > wouldn't naming it like that make more sense:
> >
> >   void     gtk_file_async_handle_cancel_operation (GtkFileAsyncHandle
> >   *handle);
>
> I went with the name gtk_file_system_cancel_operation() for now, because
> the cancel operation needs to be implemented by the GtkFileSystem
> backend.  So I think it makes sense here to have the prefix
> "gtk_file_system_".
>
> Also, I guess you are also thinking of dropping the GtkFileSystem
> argument from all callbacks, if we decide to include it in the
> GtkFileSystemHandle?

yes, i don't see a point in dragging the GtkFileSystem alongside a
private handle that you can use to store anything inside anyway.
this gets especially cumbersome with gtk/signals/main-loops as in
most places we only have a single data pointer available.

> > oh, and is this actually going to be a ref-countable object?
>
> The plan was to have each async function return a newly allocated
> handle, which is not ref-countable.

i can't exactly envision the ways this is going to be used in,
but it might make sense to have this handle actually be a GObject,
so that the file system user can at least reference count it when
passing it around (could already be useful for e.g. passing a handle
as data argument to an idle handler or signal handler).

> > i think this has been raised in some of the other comment emails already:
> > since the callback handler will have to deal with errors anyway, you could
> > make it easier on the caller if you removed the error argument from all
> > the gtk_file_system_*() functions and deliver the errors only through the
> > callback. that means the caller has to implement error handling only once.
>
> Yep.
>
> > shouldn't this have a GtkFileSystemHandle* ?
> >
> > same here, shouldn't this have a GtkFileSystemHandle* ?
>
> Yes, I forgot to add those in my mail.
>
> > >  GdkPixbuf *gtk_file_system_volume_get_icon (GtkFileSystem
> > >  *file_system,
> > >                                              GtkFileSystemVolume  *volume,
> > >                                              gint
> > >                                              pixel_size,
> > >                                              GError              **error);
> >
> > couldn't you just leave gtk_file_system_volume_render_icon() the way it is,
> > and introduce
> >   GdkPixbuf* gtk_file_info_render_icon (GtkFileInfo *file_info,
> >                                         GtkWidget   *widget,
> >                                         gint         pixel_size,
> >                                         GError     **error);
> > instead of introducing a _get variant that just takes the widget argument
> > implicitely from some place else?
>
> This sounds like a very good idea, and should be possible to do (unless
> I am overlooking something).  I will also adapt the propsal at this
> point.

great. would you mind sending around an updated API proposal then,
that incorporates all your alteration plans?


> thanks,
>
> -kris.

---
ciaoTJ