Re: Updated undo patch

[Cosimo Cecchi <cosimoc gnome org>]

On Thu, 2012-01-12 at 22:28 +0100, Amos Brocco wrote:
> Hello everybody,
> I had some time to re-sync my patch with the current git master... the
> patch is https://bugzilla.gnome.org/attachment.cgi?id=205141
> The structure of the code has not changed, I've just fixed some
> constants and replaced deprecated methods.
> Cosimo, do you think that it would be "mergeable" soon? 

Hi Amos, thanks for this update, and sorry it took me a while to answer
this. I tried the patch and I believe it still needs a bit more work to
be mergeable. I pushed a wip/undo branch in the Nautilus git repository
with your patch, so we can fix things incrementally there. Feel free to
push to that branch!

Things that I've seen by playing around with it a bit:
- dialogs spawned by the undone operations were not parented to the
caller window. I fixed this in the wip/undo branch
- the operation stack gets shifted immediately after an Undo/Redo
command is triggered, and it doesn't wait for the completion of the
operation. I believe if the operation is canceled by the user (e.g. if
it involves deleting files), we should re-add it at the same place so
that's it e.g. undo-able again; also if the operation fails for some
other reason we should remove it from the stack completely instead of
offering an option to redo the opposite again; I have some code for this
but it's not good enough yet

> Concerning your last comments: 
> - refactoring can be done subsequently, although it might complicate
> things. For example, if we merge the undo structures with the
> nautilus-file-operations ones, we would need to 
> modify some fields (like file lists) on the fly, in order to track
> files that get ignored by the user (for example during a copy
> operation) or filenames that change (ex. with duplicate).

Right; I think we can punt this and merge the patch without it.

> - in my opinion the idea of letting the user un-do just the last
> operation is not very user friendly, 
> and too much Apple Finder. 

I also discussed this with GNOME designers today and they concur with me
a stack is just overkill for a file manager (unless you can handle
filesystem transactions/rollbacks directly and do it TimeMachine-style).
So I think we want to settle with a one-operation depth for now. This
will also allow some simplification of the FileUndoManager object
operation queue internally.

Overall it's looking good anyway; I won't have much time to work on
this, but I think with some help we could get this merged for 3.4.

Cheers,
Cosimo