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 -- nautilus-list mailing list nautilus-list@gnome.org http://mail.gnome.org/mailman/listinfo/nautilus-list
