Re: Proposal for making the GtkFileChooser code asynchronous



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]