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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
