Re: [api-dev] Attempt for an UNO Undo API
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-dev] AddOn works on Windows but not on Linux
Hi! My AddOn works fine on Windows but when i try to test it with Ubuntu im not able to even see the toolbar. I'm using same version of OpenOffice on both systems. I can install the extension without problems. What could be wrong with my AddOn? Thanks, Martin - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
[api-dev] Re: Attempt for an UNO Undo API
On 18/10/2010 14:55, Malte Timmermann wrote: 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. this is probably one of the reasons why using Undo/Redo in writer is the fastest way to crash OOo... using bare pointers to objects that are not owned by the Undo action is a horrible idea. making copies of data is an acceptable overhead of an Undo implementation that actually _works_. [oh, and what you said is not actually true for paragraphs, but lots of other stuff] -- That's what C++ is all about: the development of your ethical judgment. Everybody can tell good from bad; choosing between the ugly and the disgusting takes real wisdom. -- Yossi Kreinin - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
[api-dev] Re: Attempt for an UNO Undo API
Hi Malte, Michael, Am Mon, 18 Oct 2010 15:46:00 +0200 schrieb Michael Stahl michael.x.st...@oracle.com: On 18/10/2010 14:55, Malte Timmermann wrote: 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. That is broken by design. 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. this is probably one of the reasons why using Undo/Redo in writer is the fastest way to crash OOo... using bare pointers to objects that are not owned by the Undo action is a horrible idea. +1 making copies of data is an acceptable overhead of an Undo implementation that actually _works_. +1 [oh, and what you said is not actually true for paragraphs, but lots of other stuff] - Create page style - Delete newly created page style - undo twice = crash (issue i92304, fixed in cws swbookmarkfixes01) BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Re: Attempt for an UNO Undo API
I agree that the pointer stuff is bad, but I don't fully agree with broken by design. From a user's perspective, it would look more broken when deleting a selection with 50+ pages would take a reasonable amount of time, only because some expensive Undo information is being created, which probably will never be used. But if you insist, you can also find other examples where resources might not be available anymore. Or implementations w/o support for ref counting: For example, each EditEngine Undo action needs to have an EditEngine*. And EditEngines in OOo are destroyed and re-created quite frequently. Currently there is no problem, because the EditEngine also has it's own UndoManager, which simply will vanish when the EditEngine is being destroyed. When the EditEngine would put it's UndoAction in SW's UndoManager, it would have a problem Work around would be to make every undo action a component listener, so it could invalidate the EditEngine pointer or reference. This way, you avoid the crashes, but you still have the Undo Actions on the Stack. When the user now wants to perform Undo, nothing will happen, which might be supprsing. Maybe the Undo needs some valid state, or also being able to dispose itself when it needs to do, and the the UndoManager needs to listen for that. I don't know what the best solution is, but I know that it's not easy to get undo right... I am also not sure if we really need to create the Eierlegende Wollmilchsau with a new Undo API, or if most people wouldn't already be happy with some API at the document level where the can perform StartUndoContext/EndUndoContext/Undo/Redo/Repeat/EnableUndo. Could be some XUndo API very similar to XUndoManager, but w/o addUndo() and the hidden stuff. Then the modifiable UndoManager (addUndo and what ever else is needed) and XUndoAction stuff could be an extra step / optional implementation. Malte. Björn Michaelsen wrote, On 10/18/10 16:27: Hi Malte, Michael, Am Mon, 18 Oct 2010 15:46:00 +0200 schrieb Michael Stahl michael.x.st...@oracle.com: On 18/10/2010 14:55, Malte Timmermann wrote: 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. That is broken by design. 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. this is probably one of the reasons why using Undo/Redo in writer is the fastest way to crash OOo... using bare pointers to objects that are not owned by the Undo action is a horrible idea. +1 making copies of data is an acceptable overhead of an Undo implementation that actually _works_. +1 [oh, and what you said is not actually true for paragraphs, but lots of other stuff] - Create page style - Delete newly created page style - undo twice = crash (issue i92304, fixed in cws swbookmarkfixes01) BR, Bjoern - 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
Re: [api-dev] Re: Attempt for an UNO Undo API
On Mon, 18 Oct 2010 17:16:32 +0200 Malte Timmermann malte.timmerm...@oracle.com wrote: I agree that the pointer stuff is bad, but I don't fully agree with broken by design. From a user's perspective, it would look more broken when deleting a selection with 50+ pages would take a reasonable amount of time, only because some expensive Undo information is being created, which probably will never be used. It is still broken by design. Either you provide stable undo operations for a scenario or you do not provide undo operations for the scenario at all. Because you can also be certain that the user you speak of would prefer no undo for tricky operations rather than an undo stack than sometimes crahes the application. I am also not sure if we really need to create the Eierlegende Wollmilchsau with a new Undo API, or if most people wouldn't already be happy with some API at the document level where the can perform StartUndoContext/EndUndoContext/Undo/Redo/Repeat/EnableUndo. No need for that german pig. However, what is desperately needed is a basic general concept not only for the interface, but also for the implementation of undo, including some design patterns (like for example the simple undo guard proposed in i114888). Otherwise we will end up with conflicting designs, which is hard to clean up. To clarify: I dont want to rewrite all of undo at once -- but at least we should have a shared and documented vision how it is _supposed_ to work. BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
