Godot: Changing scene tabs is an undo-able action (Or, undo is not locked to current scene)

Created on 12 Oct 2016  路  8Comments  路  Source: godotengine/godot

_Bugsquad edit:_ TL;DR: UndoRedo should work per-scene, having it undo stuff in all open scenes is very counter-intuitive and provides a bad UX.


While under the effect of issue #6772 and pressing the undo shortcut more than I should, I noticed opening another scene tab is somehow an event that counts towards undo. While this could be subjected to discussion, it seems like a wrong thing to do, as one expects the undo buffer to be contextual to the currently selected scene. Not to mention spurious events can push potentially important changes from the undo stack.

As further testing, I made a number of changes in separate scenes, mashing undo proceeded to do the entire sequence in reverse instead of undoing the changes in the scene I had selected, including changing scenes. Making some memory of things, it explains some unexpected effects I've encountered during longer work sessions but I didn't quite think of it at the time.

Why this can be problematic:
Say I have a scene "1" that is something like a visual effect, like a explosion.
1) I make two changes to "1" and seem satisfied with the result.
2) I open a scene "2" and include "1" in it. (at least 1-2 changes)
3) I make a last-minute change to "1"
4) I run the project, but I don't like how "1" looks like in action. So I decide to undo changes.
5) I undo twice, suddenly I am back to "2"
6) I keep undoing, and all changes to "2" are undone before I can reach "1" again.
7) I have undone the changes in "1", but as a result I erased all changes in "2".

This presents a large number of small-to-grave issues during the workflow:
1) It requires to mentally keep track of what scenes have been undone, and fix all "unwanted" undos (and with changes the "redo" buffer becomes nullified)
2) In case the changes become too difficult to undo, it requires a copy to restore or a version control (as in git) commit to revert to. While it's good practice to have such things, it's not always readily available, specially if it's a big change or a thing requiring several small tweaks, or some change done by pure chance (it happens). Note that for changes to be shown in the main project files have to be saved, so a basic reverting stops becoming an option every time the project is run. (read: not every scene does what one wants individually)
3) Having to restore the changes requires interrupting your workflow to restore the file.
4) If the file was created recently and there's no backup or recent commit, well, it might be impossible to restore to a "proper" point and has to be remade from scratch.

While one can argue that such potential mistakes can be avoided by being super careful, accidents/oversights/distractions happen. We are human after all. And projects can grow pretty large with a lot of files being juggled and changed all at once, or having to step away from the computer and forgetting you made change X in file Y.

archived discussion enhancement editor usability

Most helpful comment

It's a duplicate of #3511 which was closed as wontfix by @reduz. But to be honest I'm not satisfied with such a resolution, the way undoredo works for multiple scene edition is really unwieldy, and we need to find a way around it. We now have the opportunity to break compatibility if needed to make this possible.

All 8 comments

It's a duplicate of #3511 which was closed as wontfix by @reduz. But to be honest I'm not satisfied with such a resolution, the way undoredo works for multiple scene edition is really unwieldy, and we need to find a way around it. We now have the opportunity to break compatibility if needed to make this possible.

I would make UndoRedo per tab like the OP said. I would make scripts being separate tabs along the scene tabs, too, but I think this belongs to a separate issue.

this is really anoying

This is not a problem of breaking compatibility, it's a design issue, let me explain...

  • Godot lets you open multiple scenes at the same time
  • But resources are always unique in Godot, so they are shared between the open scenes
  • If you do edition to a resource in one tab, then switch to another tab and undo, you risk having an inconsistent undo history. This can lead to crashes due to objects not being as the undo/redo state expects them to be

So, unfortunately, I don't think this is possible to fix. I will kick to 3.1 in case you have any idea, but honestly nothing comes to mind without creating an abysmally big hack.

Kicking to 3.2, I don't think this fixable, but leaving open to make you guys happy :)

What if Resources had an UndoRedo history independent from scene tabs (like, stored in some ResourceManager singleton or whatever exists and fits)? Then either undo for resources could get a separate shortcut (like Ctrl+Alt+Z) OR there could be a second-level undo history, which would be a collective of undo actions from different UndoRedos.

For the second idea, here's how it could work:

  • User does ActionA in Scene A
  • User switches to Scene B and does ActionB
  • User does ActionC on a resource

ActionA is stored in Scene A's UndoRedo.
ActionB in Scene B
And ActionC in some hypothetical ResourceManager's UndoRedo

User presses Ctrl+Z
ResourceManager will undo ActionC
Ctrl+Z again
Depending on current scene tab, either ActionA or ActionB is undid.

Another case:

  • ActionA
  • ActionC
  • ActionA2
  • ActionB

When doing three CTRL+Zs in Scene A, the order is:
Undo ActionA2
Undo ActionC
Undo ActionA

When in Scene B:
Undo ActionB
Undo ActionC
Nothing to undo

Also, undos to scene's local resources would be stored in scene's UndoRedo.

Maybe that all sounds confusing, but if we ensure that resource edits are independent from scene edits, this could work. Maybe >_>

Intellij-based IDE's will occasionally give you an error when you try to undo a change (like a refactor) that affects multiple files, iff one of those other files has been modified since that change occurred.

(This might cause an error more often in Godot than an IDE, but it's an idea) What if, when attempting to undo a change to a resource, the editor would first check that no other changes have been made to it from other tabs, and disallow the undo if so (preferably giving a helpful error message about which files the changes were made in).

This may sound like it would be frustrating if the user expected to undo an action and couldn't -- indeed it is sometimes frustrating with Intellij. However, I'm already occasionally ending up at "Nothing to undo" unexpectedly anyway, and I find the undo button changing my tab much more jarring and unexpected than an error message.

Was this page helpful?
0 / 5 - 0 ratings