Re: What to return in async transfer callbacks?

[Matthias Kaeppler <noreply finitestate org>]

Christian Neumair wrote:
> Depends on what you want to do, i.e. what member of
> GnomeVFSXferOverwriteAction you pick as retval.
I have set the overwrite action to GNOME_VFS_XFER_OVERWRITE_MODE_QUERY, 
so the sync callback gets called whenever an overwrite action is 
attempted. But still, although I know which values I could possibly 
return in the signal handler, I still don't know which one exactly to 
return by default. It's not GNOME_VFS_OK, because returning this in the 
sync callback will cancel the transfer.

> You should also be able to pass GNOME_VFS_XFER_USE_UNIQUE_NAMES as XFer
> option, which should make GnomeVFS query you for a new name (cf.
> new_file_transfer_callback/GNOME_VFS_XFER_PROGRESS_STATUS_DUPLICATE in
> nautilus-file-operations.c, which Alex already pointed out).
Ah that's cool, didn't know that. By the way, are you sure about that 
filename? I just downloaded the nautilus source and it didn't include a 
file by the name of nautilus-file-operations.c. But I'll just `grep` my 
way through the files and see if it spits out the name of the transfer 
callback ;-)

> Also note that the Xfer functions have proved to be quiet buggy under
> some circumstances throughout the last few months. The debugging efforts
> continue, but since at the moment almost only Nautilus uses our Xfer API
> it might take some time to get the whole xfer process really clean.
> Pleas help :)
That's okay. As I said, I haven't done much yet with gnome-vfs, but I 
have already incorporated some basic stuff in my app, so maybe I can be 
of help once I am more familiar with the API.

> Weird. I wonder whether you casted your function when passing it to
> gnome_vfs_xfer_uri. Maybe it's yet another "Welcome to the wonderful
> worl of C" issue - you can pass functions with arbitrary signatures (and
> therefore retvals) as function pointers if you cast them to the expected
> signature. This means however, that - in the case of passing a function
> with a void signature casted to a function with an int retval - the
> value and therefore the interpretation of the retval is undefined.
Hehe, yeah that's probably it. No, I'm not casting the function but I am 
wrapping it in a sigc functor, which is then passed to the transfer 
function. This makes using the callbacks a typesafe process, because 
effectively an object is passed and not a function pointer, so I'm 
pretty sure about not passing a function with a bad signature (if I 
would do that, g++ would spit out template error messages which are long 
enough to fill a book).

Best regards,
Matthias Kaeppler