Re: Updated proposal for making the GtkFileChooser code asynchronous

[Kristian Rietveld <kris imendio com>]

On Fri, Dec 09, 2005 at 09:27:02PM +0100, Soeren Sandmann wrote:
> 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?

Yes, the callback is always called.  In the callback the cancelled flag
in GtkFileSystemHandle will have to be checked.  This flag will only be
TRUE if all of the following conditions are true:
  - The user requested the operation to be cancelled.
  - The operation was cancelled while being executed.
  - The temporary results got rolled back.  If the operation was already
    completed, we cannot roll back the changes and the cancellation will
    thus be ignored.
That means that if you cancel a create folder operation and the folder
was already created, the result cannot be rolled back and the cancelled
flag will be set to FALSE.

> >    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?)?

You're not expected to free it, I'll make the error arguments const.


thanks,

-kris.