Undo/Redo and tool scripts

jonSS That's all the code. I never said the class will appear on the list of nodes. It won't because it inherits an abstract class. You can just attach the Drawable script to any existing canvas item node and it will work. But that all is beside the point. You can inherit any other canvas item class. Makes no difference for what the example is about.

The color is for the whole node. It's just to differentiate between the nodes so we can see how undo properly functions with multiple nodes. Not meant to work as some kind of brush color and it's not included in the undoable action. Although that'd be easy to implement. I'm leaving it to you as a homework.

I'm here in the business of demonstrating the basic key concepts in the most compact form, not finetuning the user experience

jonSS Inspector plugin has nothing to do with undo. Undo happens with the data, not with the interface that displays it.

jonSS For some reason its reseting it

Who resets what? Remember that this is not a thread about your project. Have you managed to implement a simple undo system on your own in a fresh project following the model shown in my example? Do that and it'll make things a bit clearer. Don't just copypaste. Make your own variations. Add stuff to it. Do "what if" experiments with it. Tinker until you gain full understanding of how it works.

Again, the inspector has nothing to do with undo. If you're storing undoable data in an inspector then your architecture is not properly done. All undoable data needs to be on edited node's side. An inspector should only read that data and display it. Akin to classical model-view-controller design pattern.

Typically you'd implement something like update() or refresh() method in your inspector and call it every time you want to refresh what the inspector displays. In that method you'd read all the relevant data from the edited node and set the inspector's state accordingly. Everything that lives in the inspector should be totally disposable.

Also, not directly related, but all viewport input concerning the plugin (e.g. editing plugin supported nodes...) is best handled in EditorPlugin::_forward_*_gui_input(). See my example.

For the record, here's an example undo project that contains only my above code.

Lo and behold - it works! Who would've thunk it?

jonSS Your arrogant attitude doesn't warrant this but here it is anyway

Does undo work? Of course it does. Shocking, I know. Editor inspector plugin has nothing to do with undo, did I already say that?

I suggest deleting that post on github unless you want to embarrass yourself. The only "issue" there is the lack of understanding of how this stuff is supposed to operate. I won't waste any more time trying to explain it to you just to be called an idiot in return. You don't listen. Here's the example with editor inspector plugin added on top. Learn from it. Or don't. Good luck ️

Tomcat PEBKAM, as they used to say back in the day

jonSS EditorInspectorPlugin::_parse_begin() is supposed to be called every time you select a node supported by EditorInspectorPlugin::_can_handle(). Nothing gets "reset". Custom controls scene is supposed to be instantiated every time this happens. Its _ready() is supposed to be called. You're complaining about things that happen by design.

The skipped undo is due to possible bug in color picker gui modality. If you click into viewport with the color picker still open, EditorPlugin::_forward_canvas_gui_input() wont register mousedown event nor its counterpart mouseup event. This is the actual thing that may be worth reporting.

For simplicity, my example was checking only for mouseup and mousemove envents. It implies stroke state instead of tracking it via a flag set by a received mousedown. Because of that, the stroke you start when a color picker is still visible won't make it into the undo queue.

Easy fix by adding a flag into mouse input logic. It will now require an additional viewport click when trying to stroke from an open color picker. Courtesy of an apparent color picker glitch.

All this is just menial gui stuff. Nothing to do with the core undo mechanism we're trying to demonstrate here.

Now be a darling and check and report back how you feel undo performs in the project below.

jonSS Only wanted to address complaints about my example "not working". It works and it shows how undo is properly implemented. The rest of your questions have already been answered. Go re-read my posts.

Here's a hint; You do stuff with that dictionary outside of do/undo functions. Once you introduce undo functionality, all changes to that dictionary should be contained within those functions. Otherwise the thing will likely fall apart. And that's precisely what you're witnessing there.

Either that or the devs are intentionally destroying the engine, eh?

jonSS Look at it from the bright side. Out of the whole ordeal you've learned one thing for sure - that it's spelled redo and not reNdo.

jonSS Btw the inspector refresh that is breaking your heart is triggered by notify_property_list_changed() called from undo/redo functions. This is again by design. The sole purpose of this function is precisely that - to refresh the inspector.

Also, you need to remove the inspector plugin in EditorPlugin::_exit_tree() by calling EdtorPlugin::remove_inspector_plugin(). Otherwise the custom inspector gets multiplied with every restart of the plugin.

Go do an arkanoid clone or something. Plugins are messing with your mind