Re: Nautilus Undo

[Alexander Larsson <alexl redhat com>]

On Fri, 2007-10-19 at 18:17 +0200, BROCCO Amos wrote:
> Hello,
> I'm implementing an undo mechanism for Nautilus (see [1]).
> 
> I've already implemented some code [2] to manage a global operation
> history (nautilus-undostack-manager), menu entries and callbacks.
> 
> As there is work being done to move from gnome-vfs to gvfs I've not
> yet added the code to actually undo-redo file operations;
> at this moment, selecting Undo or Redo does not perform real file
> operations but just prints a message on the console.
> I've put some placeholders in nautilus-file-operations.c where the
> code to construct "undo data" will be put.
> 
> I've considered that every file operation (including undo/redo) is
> performed asynchronously, so the history is protected
> using a mutex. Updates for the UI (menu items sensitivity, labels and
> tooltips) are pushed, when necessary, by mean of signals
> (the UI being FMDirectoryView).
> 
> Some additional info on how the undo history works is found in
> nautilus-undostack-manager.c .
> 
> Comments/advices/critics/questions/help are welcome (thank you in
> advance :) )
> 
I haven't looked at the patch yet, as I'm at the moment deep into the
gio-branch work and need to get that finished asap. However, I have some
questions on how this is meant to work.

If I copy a file over another file. How do you undo that?
If I copy a directory and the copied files are merged into an existing
directory, can it undo that?
What happens if you try to undo something, and a process external to
nautilus has modified the filesystem since the operation nautilus is to
undo. (For instance, removed the file you're moving back.)

And in general, is it a good idea to expose an undo system in the UI
when its gonna have so many cases like this when it doesn't work? Users
might rely on it and then loose data when undo unexpectedly doesn't
work.