[WebODF] Undo/redo actions

[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 [...]


You just missed my proposal mere paragraphs away that suggests the same
thing :)


> [...]
> 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.
>

Correct. This should also be possible (though, how desirable? I'm unsure)


> Would also mean no need for the complexity of a dedicated undo/redo
> manager.
>

I disagree. You will still (always) require a dedicated undo-redo manager.
For example,
in LibreOffice (and many editors), typing consecutive letters without
changing the
cursor position in between is undone as a single block. This grouping
happens after
each individual operation is fired away. (If you look at the current undo
manager it
is actually rather straightforward... not as much complexity in there as
you fear
I assure you! :)  )


> 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.
>

This is the main reason I was raising this. Rather than having the undo op
be immediately available when the original op is created, it will likely be
easier
to literally generate the undo op *whilst* applying the original. This
means less
traffic for everyone, and (theoretically) allows all the benefits one would
expect
from an undo stack.


> 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.
>

Correct. I agree with this fully! But, nowhere have you said that undo
needs to
result in exactly the same document as before the (now undo) operation was
performed. So... is it safe to say that "visually identical" is acceptable,
even if the document is "changed"? :)

---
Philip Peitsch
Mob: 0439 810 260
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open.nlnet.nl/pipermail/webodf/attachments/20130731/bd7f40b0/attachment.html>