| Summary: | results of cancelling a move files operation is gui counter-intuitive - make cancel == undo | ||
|---|---|---|---|
| Product: | [Applications] konqueror | Reporter: | Charles Phoenix <phoenixreads> |
| Component: | general | Assignee: | David Faure <faure> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | wishlist | CC: | finex, peter.penz19 |
| Priority: | NOR | ||
| Version: | 3.3 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
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... > 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. This bug should be considered in KDE 4 either. "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. |
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?