It is inconceivable that user initiated modifications to the view cannot be undone; having the user manually undo them by whatever interaction tools they have to reverse the effects is not very reasonable approaching the year 2016. It's sort of a User eXperience dead end. This change should be done along with improving the separation between model and render layers.
Basic design can be:
- every action changing the view will be wrapped with a new function
doWithUndo, which will push the current display state into an undo-redo buffer, before executing the action. E.g. doWithUndo(addNodeGroup(params)).
- an Undo function (here, it might benefit from d3's data driven animations, which can make the undo look gradual inline with the rest of the "feel").
- a
redo function which moves the undo-redo pointer across the undo-redo array
- Some these functions will have to appropriately invalidate redos/undos once performed, to provide the consistent experience of undo/redo that we have in most applications that support undo-redo.
Those would be the high-level api. The lower level api serving them may be something like:
historyBuffergetMaxSize - maximum size allowed for the buffer being somehow determined automatically relative to the amount of memory available or something like that.getCurrentBufferSize - using the function sizeof or otherwise.trimBuffer for pushing in a new snapshot while freeing up space by removing the oldest undo or something like that
So we have a buffer and a pointer.
What can be undone and redone?
- nodes on display
- node locations too! if window size changed, they should be ignored though (or adjusted in a simple way that is cognition-friendly)
What preserves during undo?
- selection status, (whether a node is selected or not); as much as the nodes are still on display after the undo; Give this a little more thought.
It is inconceivable that user initiated modifications to the view cannot be undone; having the user manually undo them by whatever interaction tools they have to reverse the effects is not very reasonable approaching the year 2016. It's sort of a User eXperience dead end. This change should be done along with improving the separation between model and render layers.
Basic design can be:
doWithUndo, which will push the current display state into an undo-redo buffer, before executing the action. E.g.doWithUndo(addNodeGroup(params)).redofunction which moves the undo-redo pointer across the undo-redo arrayThose would be the high-level api. The lower level api serving them may be something like:
historyBuffergetMaxSize- maximum size allowed for the buffer being somehow determined automatically relative to the amount of memory available or something like that.getCurrentBufferSize- using the functionsizeofor otherwise.trimBufferfor pushing in a new snapshot while freeing up space by removing the oldest undo or something like thatSo we have a buffer and a pointer.
What can be undone and redone?
What preserves during undo?