Bug 91579 - results of cancelling a move files operation is gui counter-intuitive - make cancel == undo
Summary: results of cancelling a move files operation is gui counter-intuitive - make ...
Status: RESOLVED INTENTIONAL
Alias: None
Product: konqueror
Classification: Applications
Component: general (show other bugs)
Version: 3.3
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-10-18 11:30 UTC by Charles Phoenix
Modified: 2009-09-17 17:11 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Charles Phoenix 2004-10-18 11:30:44 UTC
Version:           3.3 (using KDE 3.3.0, Gentoo)
Compiler:          gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)
OS:                Linux (i686) release 2.6.7-win4lin-r4

When you cancel a move operation, one's files are in two locations... all moved files are in the new location and the remaining files are in the original location.

It makes perfect sense from a command-line interface perspective.
That is, cancel is actually means stop current command (ctrl-c) and is more or less consistent.

Yet from a gui perspective the meaning of cancel is "return me to the previous state before I executed the command".

This functionality can easily be achieved by recording the files being moved and either returning them back to their original location automatically ("Please wait...") or asking the user if they want the file location restored.

I have lost count of how many times I swore at KDE for moving files by accident (delayed/accidental mouse movement during temporary gui freezes). An undo funcational would at least make it easy to fix. Now where did those files go again?
Comment 1 David Faure 2007-01-19 23:19:12 UTC
I disagree, the meaning of cancel is really "abort as soon as possible".
All applications I know (and especially file managers) work this way.
We offer "undo" already (Ctrl+Z), for undoing a copy or move operation.
I haven't tested it much with the case of cancelling a move operation midway though...
Comment 2 Dotan Cohen 2008-03-06 22:19:14 UTC
> I disagree, the meaning of cancel is really "abort as soon as possible".

Then the text should be changed from "cancel" to "abort".

> All applications I know (and especially file managers) work this way. 

That is certainly no reason to say that KDE cannot do better. This is a problem with other file managers, true. That does not mean that it has to be a problem with KDE.

When the user chooses cancel, all the operations that were done up until the failure point should be undone. Canceled operations should not leave work half done.
Comment 3 FiNeX 2009-09-17 15:56:52 UTC
This bug should be considered in KDE 4 either.
Comment 4 David Faure 2009-09-17 17:11:52 UTC
"Cancel" _means_ "Abort".
If you start burning a CD and press Cancel, you won't get a blank CD back ;)
But well, the naming is probably a question for the usability folk, if one wanted to move this further.

But from a technical point of view, because undo'ing has its own set of problems, I don't think it would safe to always undo. E.g. you start moving your kde sources somewhere else, and after 15 minutes your plane is about to board and you have to shut down immediately. You press cancel - no such luck, the undo'ing will take another 15 minutes... :-)
Cancel is really "abort now", in all known uses of cancel.
Even if you end up with a half-done operation.