Undo for Transform Gizmo actions

[cadaver]

The Undo/Redo code was recently merged. However, it is missing undoability for Transform Gizmo actions (translate/rotate/scale). These should be implemented. Note: to not cause large memory usage during to prolonged dragging, only the start and end of the gizmo action should be recorded.

[jonnenauha]

Yeah snapshots on start or dragging and when dragging is released would be super nice. I recon history of ~50 latest moves could be a sensible default?

@cvetan5 the undo/redo stack is always per ec editor window or do they share the history somehow?

[cvetan5]

No it is per EC / Scene editor only. It can be made to be shared though I don't know if it is convenient. Better to get some feedback from end users about that to make sure.

[jonnenauha]

I was just asking, I think its better and makes more sense that each editor has their own memory. It will be nice for advanced users that have multiple editors open :)

How hard will it be to implement this? I'd pump this up on the priority list as seems like a super useful feature.

[cvetan5]

It's trivial, you can pump it up I guess

[jonnenauha]

We'll its up to you of course, you schedule the rex foundation work. I think if you can squeeze this before next release it would be nice, but not a must have.

Btw. @Stinkfist0 is writing a build mode for Rocket. I was thinking if the undo/redo logic/classes are separated so that Ali could utilize them also in our build mode? We wont be exposing EC editor there but custom UI. Still if the mem logic just tracks attribute changes from a entity (or a group of entities) it could probably be used as is.

[cvetan5]

Yes of course, it is not tied to ECEditorModule, apart from the files being there. However, it is not tied to common scene elements signals, because that would mean, for example, tracking entity / component / attribute changes made from some script etc... One can use all the classes from there, or just a plain QUndoStack if one does not want the UI elements. In the case of the latter, be sure to remember to instantiate a single EntityIdChangeTracker that will be alive as long as the history of commands requires to, and to pass the pointer to some of the commands. In general, this is what you do:

    ...
    // About to write code to add an entity, but instead I'll write this, because AddEntityCommand::redo() already
    // has the code to do so, and it's called immediately when it's pushed onto the stack
    myUndoStack->push(new AddEntityCommand(...));
    ...