Hi Philip, no time for detailed reply today, but definitely interesting topic, which can be seen already to sit & wait directly on our way into the future :) Am Mittwoch, 31. Juli 2013, 04:28:23 schrieb Philip Peitsch:
Hi everybody,
I've been considering the following thought experiment for undo/redo:
1. Doc state = A 2. Op A is performed by Mandy, Doc state = B 3. Op B is performed by Fred, Doc state = C 4. Mandy hits undo on her local editor 5. Doc state = ??
What does Mandy expect to have happen? Does this undo Op A or Op B?
Another option would be to just have Undo to be another new operation which just is the invert of the op that should be undone. Which means the original op will stay part of the op stack, and "just" a new one is added on top. Then no special handling of ops is needed, and transformation can be done as before. It might be also possible to undo any op in the stack (given the inverted op can be transformed through the rest of the op stack). So the UI could offer to just undo your own last ops, or undo ops/actions from everyone. Would also mean no need for the complexity of a dedicated undo/redo manager. But also means that your accidental paste of a private message to your better half will also after "undo!!!" stay in the op history, uh :) (though doing deletion surgery on the op stack could be another future feature to have) Of course this requires that all info needed to invert an operation is still available, like the properties of removed styles, overwritten style properties, removed text, etc. Which means quite some changes to our current opspecs and op creation code, but this should not stop us, at least in the long run. In any case we should see to keep clients ODTs as convergent as possible, ideally 100 %. Anything else might only mean troubles later and hard to reproduce errors, my gut tells. Cheers Friedrich -- Friedrich W. H. Kossebau // KO GmbH http://kogmbh.com/legal/