Kristian Rietveld <[EMAIL PROTECTED]> writes: > 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. The GtkFileSystemHandle will be a GObject: > > struct _GtkFileSystemHandle > { > GObject parent_instance; > > GtkFileSystem *file_system; > > guint cancelled : 1; /* indicates whether the operation > has been cancelled or not */ > }; > > struct _GtkFileSystemHandleClass > { > GObjectClass parent_class; > }; > > File system backends can of course subclass GtkFileSystemHandle and > add their own fields as required. We will add a call which we can use to > actually cancel an operation: > > void gtk_file_system_cancel_operation (GtkFileSystemHandle > *handle);
If you cancel an operation such as create_folder() before the callback is called, what are the semantics? 1 the operation will not have been completed, ie., no folder was created and no folder will be created 2 the operation may or may not be completed depending on where the thread happens to be when you cancel the operation 3 the operation will be completed anyway 4 something else Number 1 seems impossible to implement with threads without getting into hairy things like thread cancellation. Number 2 seems nasty, and 3 makes cancelling pretty useless. Also, the callback is always called, even if you cancel the operation, right? > The function gtk_file_system_get_info() itself does not take an > GError argument. All errors will be reported via the callback, this means > that error handling will only have to be implemented at a single place. > The error argument of the callback will be NULL when no error > occurred. Shouldn't error be const, or are you expected to free it (if so, why?)? Soren _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list