Hi Ingrid, I must admit that I didn't look more deeply into the proposal yet, so just some comments on your comments:
If an action in Calc leads to changes in Chart, and Calc triggers the changes actively, Chart doesn't necessarily need it's own actions in that case. When I perform Undo in Calc, it will also lead to necessary changes in Chart. So depending on the implementation, it can have side effects if some implementation thinks it is responsible for updating other data, which is then also been done buy any others implementations Undo. Whether this will have unwanted effects mainly depends on how much status information the Undo action is using. For example, when the user action leads to inserting some data object in an Array of implementation A , and leads to calling Insert(nPos, pData) in implementation B. A might only recognize nPos and a copy of Data. This is good enough for undo, and also following redo. But since that implementation probably doesn't keep a full data array as Undo data, the implementation will probably look similar. In the end, one Undo could lead to removing one data object in A, but 2 in B (one in it's own Undo, 1 in Calc's Undo). But maybe this doesn't matter, because every implementation knows anyway whether or not an other Implementation does it's own undo stuff? At least it's good to be aware of this. How does an implementation actually know whether or not to create new Undo actions? On manipulations via User/API it needs to, but if manipulations are currently done because of Undo, you mustn't create new Undo actions. I see in Frank's email "determining whether an Undo/Redo operation is currently in progress", but couldn't find it in the API. Now looking into the attached API more deeply: It seems that the idea is that any extension could put it's own Undo actions in some others UndoManager. But what if the Extension terminates (no crash, but by intention), while I still work with the document? The Undo actions could have pointers to some data which doesn't exist anymore, and the extension can't remove the actions from the UndoManager. Avoiding pointers could mean making the Undo actions more "expensive" (memory, time). For example, Writer and EditEngine simply keep Paragraph* when paragraphs are being deleted completely. Last but not least: When one common API for Undo should be used everywhere longterm, it needs to have support for Repeat (which then can lead to other funny situations, when some primary undo actions don't have repeat support, while the according hidden actions have...) Malte. Ingrid Halama wrote, On 10/15/10 20:23: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
