Re: Attempt for an UNO Undo API

Hi Frank,

Frank Schönheit wrote:
> Hi,
> 
> An UNO Undo API has been a revenant in this list (and other places) for
> multiple years now.
> 
> Not sure if this year's attempt to exorcise (aka: implement) it will be
> more fruitful than previous ones, but let's see ...
> 
> The following are some thoughts I have on the topic, and assuming
> there's not too many people crying "that's complete nonsense", the plan
> is to embark on an implementation in a not too distant future.
> 
> Comments welcome.
> 
> Usage scenarios
> ===============
> 
> A. An extension operates on a document, doing multiple changes in a row.
>    All those changes should appear as a single entry in the "Undo" menu,
>    and be undone in a single step.
> 
> B. An extension listens for certain changes in a document, and reacts on
>    them with doing more changes to other parts of the document. The
>    latter change should not be visible in the Undo stack, and the Undo
>    action generated by the former change should implicitly also undo
>    the second change.
>    (Imagine the extension as ensuring a consistent state of the
>    document, with its own definition of "consistent".)
> 
> C. An extension listens for certain changes in a document, and reacts on
>    them with doing more changes to other parts of the document. When
>    both changes (the latter implicitly, the former explicitly) are
>    undone, the extension should have a chance to find out that the
>    change instigated by this Undo operation does not justify a new
>    change to the document.
> 
> D. An extension wants to add own Undo actions to the document's Undo
>    stack, providing a callback for the Undo/Redo operations.
> 
> Notes
> -----
> 
> Whenever the term "extension" is used in the above list, it could
> equally mean "every piece of client code which has UNO access to the
> document only".
> 

I think the Chart does qualify for all those Usage scenarios.
Changes in Calc can lead to changes within the Chart that should be 
offered as one UNDO action together. Further the changes made within the 
Chart should be visible in the global UNDO stack also.
So the Chart would be an ideal candidate for a test implementation. I 
would like to join your efforts, if time fits. :-)

There might be some extra complications to expect regarding the OLE 
inplace editing mode and the OLE swapping mechanism. That could become 
ugly, maybe ... .

[...]

> API proposal
> ============
> 
> XUndoAction, XUndoManager, XUndoManagerSupplier - find the generated IDL
> for the proposed API at
> http://udk.openoffice.org/files/documents/23/4795/undo.zip
> 

That looks quite good so far! Maybe we can give up the 
::com::sun::star::chart2::XUndo... things in favor of these new common 
interfaces :-).
Regarding the hidden actions, what is exactly the order of Undo/Redo 
stack execution? Lets look at the following example:
1. The deletion of a column within calc is action1 and produces an 
undoaction1.
2. A change notification to the chart leads to action2 the deletion of a 
data series with values from the deleted column. An according hidden 
undoaction2 is created.
If the user hits Undo now for a working scenario I think UndoAction1 is 
to be executed first and afterwards the hidden undoaction2.
Can this be a general rule? Hidden actions are treated after their 
visible predecessor? If so, there needs to be some care when putting 
things onto the stack or from the stack.

Kind regards,
Ingrid