Expose EditorUndoRedoManager.undo() and redo() methods to GDScript plugins for manual undo/redo capability

[vilmt]

Describe the project you are working on

An editor plugin for editing dialogue sequences using a node graph.

Describe the problem or limitation you are having in your project

My GDScript editor plugin has a window for editing user-configurable variables to use in their dialogue sequences. Values changed in this window should also have support for undo-redo actions through EditorUndoRedoManager. While this window is open, however, CTRL+Z (undo) and CTRL+Y (redo) input actions are consumed by the window.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Other parts of the engine such as the Animation Library Editor window and the floating Shader Editor window solve this issue by calling undo() and redo() directly from EditorNode whenever receiving the "ui_undo" or "ui_redo" input actions.

https://github.com/godotengine/godot/blob/master/editor/animation/animation_library_editor.cpp#L999

EditorNode (which is not available to GDScript editor plugins) then directly uses EditorUndoRedoManager.undo().

https://github.com/godotengine/godot/blob/master/editor/editor_node.cpp#L3199

If EditorUndoRedoManager.undo() and EditorUndoRedoManager.redo() were exposed to GDScript editor plugins, I could replicate this behavior seen in the engine, but it is currently impossible to do.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

To my knowledge, this simply consists of binding the methods with ClassDB. I am unsure why EditorUndoRedoManager does not expose these methods while UndoRedo does.

If this enhancement will not be used often, can it be worked around with a few lines of script?

This enhancement would enable having undo/redo buttons in an editor plugin, as it would be trivial to inform EditorUndoRedoManager about alternate undo/redo requests. It seems to be currently impossible. A possible solution could be to capture the "ui_undo" and "ui_redo" input actions and parse them in the editor's viewport? I could not get this to work.

Is there a reason why this should be core and not an add-on in the asset library?

This is about improving the core GDScript EditorUndoRedoManager experience.

[dalexeev]

Please note that if plugins misuse this functionality, it can create a very confusing user experience. Undo and redo actions in most cases must be initiated by the user so they can understand the current state of the editor. More complex cases are solved by merge modes or grouping history snapshots.

I'm not talking about absolute protection; plugins have a very high level of privileges and can break the editor (or even the user's system) in many ways. You can already achieve this functionality through a hack. I'm talking about a documented way to do it. If we expose this functionality, it means we support this use case.

Could you please describe the problem in more detail? Why do you need this functionality, and why can't it be solved using existing solutions or any other methods you can think of?

[vilmt]

My plugin has an AcceptDialog for configuring values. When the AcceptDialog (an exclusive window) is open, it consumes all undo/redo input actions initiated by the user. I don't want these actions to be consumed, as they should trigger the editor to undo/redo as usual.

The Godot Editor handles this problem case-by-case. As I mentioned, the Animation Library Editor window, for example, uses EditorNode's undo() and redo() methods, which directly call EditorUndoRedoManager's corresponding undo() and redo() methods. Essentially, each time the Godot Editor has a floating window where the editor's undo/redo must work through the shortcuts, there is a switch statement that implements it again. As neither EditorNode nor EditorUndoRedoManager's methods are exposed to GDScript editor plugins, there seems to be no documented way to trigger the editor's undo/redo functionality through code.

Could you explain how the undo/redo hack works? I could not figure it out myself, which is evidence that manual undo/redo work needs more documentation.

[KoBeWi]

I suppose an alternative is exposing this class (once it gets merged): godotengine/godot#102899