STEPS TO REPRODUCE 1. Navigate to some folder A that contains a few files 2. Delete and rename a few files in that folder 3. OPTIONAL STEP: Let several hours pass while you don't touch Dolphin (actually, you may very well use Dolphin to navigate, open and close folders, but just never do any undoable actions such as rename or delete files), and mainly use other programs where you do your work, which may include editing some of the files you renamed at step 2 4. Back to Dolphin, navigate to a completely unrelated folder B 5. Hit Ctrl+Z one or more times NOTE: step 3 is optional, just to demonstrate the potential catastrophic effects of this bug. You can omit step 3 and still clearly reproduce and (hopefully) understand the issue. EXPECTED RESULT Nothing should happen. Or if Ctrl+Z does do something, you MUST see it. Definitely it should not do something that you can't see, with no warning, and definitely it shouldn't do something in any folders other than the one you are looking at. OBSERVED RESULT Ctrl+Z undoes the latest thing you did in Dolphin, even if it was in another folder, even if it was hours ago, even if it involves files that in the meantime have been touched by other processes, and even if you don't see it and have no clue it's happening. So in the case of the steps above, it will undo whatever you did at step 2 in folder A, but you won't see any of it because you are in folder B. Given that nothing seems to happen when you hit Ctrl+Z, if you are expecting something to visibly happen because you think the last thing you did was something else, you are likely to hit it more and more times, which means you are INVISIBLY undoing more and more actions. The fact that there is "Undo" but no "Redo" (which is a separate huge bug, or design flaw) makes this even worse. This is an absolute disaster that can cause data loss without even realising. It should not be underestimated. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20220207 KDE Plasma Version: 5.24.0 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.16.5-1-default (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-1065G7 CPU @ 1.30GHz Memory: 7.3 GiB of RAM Graphics Processor: Mesa Intel® Iris® Plus Graphics
Yeah, when Undo changes something not visible, we should show the user what happened, and definitely let them Redo afterwards.
> Yeah, when Undo changes something not visible, we should show the user what happened That is absolutely a huge part of the issue but that's not all. If that "something not visible" is "something that was done in another tab/window", that shouldn't be undoable in the first place from the current tab. Each tab should have its separate undo history (which should get destroyed when you close that tab). Think of when you edit files in multiple tabs or windows in any modern text editor (or other kind of editor, e.g. images in GIMP). Would you imagine hitting Ctrl+Z in a tab, and undoing something that was done on another file in another tab? No, right? Even if that brought focus to the affected file and scrolled to the affected position and made the (un-)changes visible (which is what happens when you undo in the current focused file), that wouldn't make it acceptable. And when you close and reopen a file, you don't expect to be able to undo stuff that was done before closing and reopening the file. Analogies don't automatically hold, but I'm pretty sure this particular analogy holds quite well here.
> Each tab should have its separate undo history (which should get destroyed when you close that tab). Yeah, that seems reasonable.