Il giorno ven, 26/10/2007 alle 15.50 +0200, Alexander Larsson ha
scritto:
>
> If I copy a file over another file. How do you undo that?
In the actual implementation, the undo just deletes the file; afaik this
is the same behavior found in Windows, so it would be far from an
unexpected behavior for most of the users.
As a side note, I've observed that KDE Dolphin proposes either to rename
the file or to overwrite the existing copy. In the first case, the undo
even deletes the wrong file (the file with the original name, and not
the renamed copy!), in the latter case, the copy is deleted.
An improvement would consist in Moving to trash the existing file
instead of deleting it, so that the following undo sequence would
restore the original file: 1. Undo Copy (delete the copied items), 2.
Undo move to trash (restore the replaced item from trash).
> If I copy a directory and the copied files are merged into an existing
> directory, can it undo that?
In the actual implementation undoing will result in the whole folder to
be deleted (same behavior as in KDE Dolphin); for two reasons:
1. only the uri of the directory is stored as undo information.
2. when there is a conflict, if the user chooses "Replace",
GNOME_VFS_XFER_OVERWRITE_ACTION_REPLACE_ALL that
hides everything, we don't know which file is actually overwritten.
Solutions:
1. store a complete list of the directory contents (source uris, target
uris)
2. Avoid using GNOME_VFS_XFER_OVERWRITE_ACTION_REPLACE_ALL in order to
know exactly which file is replaced.
Another (easier and safer) solution would be to disable undo (and inform
the user about that) if the file operation involves replacing files
(this is the approach taken by Windows Explorer), even if the user
choses to skip overwriting.
> 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.)
Nothing, the action does nothing (no error is shown)... same behavior as
KDE Dolphin.
> 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.
The best we can do is to inform the user what
the undo really does or doesn't (or can do or can't), and at least avoid
that undo/redo destroy data without the user knowing about it.
--
"Make everything as simple as possible, but not simpler."
-- Albert Einstein
Amos Brocco
Ph.D Student
Computer Science Department - DIUF
University of Fribourg
Address: A406 Pérolles 21
Bd. Pérolles 90, CH-1700 Fribourg
WWW: http://diuf.unifr.ch/pai/people/broccoa
Phone: +41 026 300 8481
Attachment:
signature.asc
Description: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio firmata digitalmente