Am Montag, den 26.09.2005, 19:14 +0200 schrieb Matthias Kaeppler: > 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 can't simply return one "by default". You'll have to handle all members of GnomeVFSXferProgressStatus. For GNOME_VFS_XFER_PROGRESS_STATUS_OK, you can return TRUE. It's just important to not return FALSE (which is 0, i.e. the value of GNOME_VFS_OK, and the reason why that failed), because FALSE always means "abort now!". > > 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 ;-) libnautilus-private/nautilus-file-operations.c -- Christian Neumair <chris gnome-de org>
Attachment:
signature.asc
Description: This is a digitally signed message part