Maintaining Undo / Redo stack for EC editor and Scene editor

[cvetan5]

An Undo / Redo stack manager for EC / Scene editor. It utilizes the Undo framework classes by Qt that implement the command pattern. All actions i.e. commands from EC / Scene editor (excluding pasting content, importing scene(s) and converting local entity to replicated and vice-versa) are represented by a QUndoCommand-derived class. The undo manager manipulates the QUndoStack and the UI elements i.e. undo and redo tool buttons with two QMenus which contain 5 recent commands that had been done (Undo menu) or undone (Redo menu). A QUndoView is provided to view the contents of QUndoStack, and to walk through them if needed. A helper class called EntityIdChangeTracker is used to track IDs of entities that had been deleted / re-added in an EC / Scene editor lifetime, and also to track acknowledging of new created entities so it can keep their valid replicated ID. The reason I did this is that I don't think it is smart to use old entity IDs to redo a "delete entity" action (and for some reason it does not work for replicated entities).

Workflow:

1. When a command is executed, a new instance of the appropriate QUndoCommand-derived class is pushed onto the stack;

2. QUndoStack calls QUndoCommand::redo() of the QUndoCommand that had been pushed, except when EditAttributeCommand<T> is pushed, where the old attribute value must be stored before setting it to the new value (there is a workaround there to avoid calling redo() upon pushing). The UI is updated;

   2.1. If for example, a command that will cause a change in the target entity's ID has been pushed, its ID is tracked with EntityIdChangeTracker;

3. When UndoManager::Undo() is called, QUndoStack calls QUndoCommand::undo() of the topmost command from the stack. The index is changed to point to the next command that will be undone on the next undo() call. The UI is updated;

4. If, for example. 4 commands are undone i.e. the index is changed back by 4, QUndoStack calls QUndoCommand::undo() repeatedly until the desired index is reached. The UI is updated;

   4.1. In the event that a new command is pushed onto the stack, commands that can be redone are removed from the stack and destroyed; 4.2. Entity IDs are retrieved by recursively walking through EntityIdChangeTracker's maps

5. When "unsupported commands" are executed, it results in clearing the undo stack (removing and destroying all QUndoCommands)

Known drawbacks:

• I noticed that when showing the QUndoView, the first command that was pushed onto the stack is inevitably selected, resulting in repeated undo() calls when index 1 is reached. Upon a hastily google search I couldn't find if anyone else has this problem. This should be replaced in the future by a custom undo stack view if QUndoView is indeed buggy.
• Changing a Color attribute results in two commands pushed with same values. This is fixed by merging two EditAttributeCommand<Color> instances that have the same values.
• If two or more entities are selected in EC editor's right pane, and a common attribute value is changed, it will result in pushing multiple QUndoCommands for all target entities.

Possible drawbacks:

• EntityIdChangeTracker worked for me on local and hosted servers as expected, but needs thorough testing. My guess is, if a series of commands that include changing of IDs are undone immediately (undoing 50 commands), it is possible that EntityIdChangeTracker might lose track of those entities in a case where Scene::EntityAcked(Entity*, entity_id_t) signal might come late and the tracker will fail to store the acked ID of an unacked entity, thus resulting in a broken undo stack (the undo command will not be able to retrieve the entity ID and undoing / redoing will not have effect)

Most of the code for the commands is reused and moved to the appropriate QUndoCommand::redo() method. I would greatly appreciate if you guys test this and give me any notes on this.

[jonnenauha]

@cadaver could you give @cvetan5 a shout when you will be cheking this out so he can merge rex/tundra2 to it.

[cadaver]

Should be next week, after checking the noboost pull request.

[cadaver]

Looks good. After merging, I'll file an enhancement ticket for also recording transform gizmo actions as undo commands.