They set it up so that micro moves can only be undone and redone as long as they are not followed by a macro move. This is more powerful than wha tBiomixer currently does, which is to snapshot layouts when the "macro" change is executed (expansion). When you undo and make "micro" changes (for us, node movement of any kind, including triggering a layout), then that change will only be kept available in the undo stack if a new expansion is performed (it will take a new snapshot then). No undo is possible within the node movements except when they are the final ones prior to aexpansion, in which case they are in the snapshot.
Our way is pretty much the simplest possible design, which was my explicit goal. I considered an approach similar to KC-Viz's approach, but mine was going to allow layout transitions intersected with expansions (insofar as that is possible). See #392 for details.
I think that unless there is demand, that our current system is fine, but I wanted to enter this into the issue system for possible reference later.
In the KC-Viz interface, there is the concept of Macro and Micro layout changes, and undo/redo of them. Micro includes user node repositioning and zoom, while macro is for layout retriggers, hiding, deleting. (http://speroni.web.cs.unibo.it/publications/motta-2011-latest-developments-kc-viz.pdf).
They set it up so that micro moves can only be undone and redone as long as they are not followed by a macro move. This is more powerful than wha tBiomixer currently does, which is to snapshot layouts when the "macro" change is executed (expansion). When you undo and make "micro" changes (for us, node movement of any kind, including triggering a layout), then that change will only be kept available in the undo stack if a new expansion is performed (it will take a new snapshot then). No undo is possible within the node movements except when they are the final ones prior to aexpansion, in which case they are in the snapshot.
Our way is pretty much the simplest possible design, which was my explicit goal. I considered an approach similar to KC-Viz's approach, but mine was going to allow layout transitions intersected with expansions (insofar as that is possible). See #392 for details.
I think that unless there is demand, that our current system is fine, but I wanted to enter this into the issue system for possible reference later.