Darabos Dániel wrote: > Hi! > > Is there some work going on currently on an undo API for extensions?
We started to design an API for this quite some time ago but never found enough time to implement it. > Since I did not find any trace of it, I think I will try to create > this API myself. Defining the API is comparably easy (and your "whish list" looks fine to me). The hard part is the implementation ... > I cannot tell if these are even possible -- this is why I am writing > to this mailing list. Also please add any more wishes, maybe I will be > able to "make them come true" :). I hope I can find some traces of our former discussions about it. > And since I am primarily developing extensions these days I see how > much an undo API would be needed. Any extension right now has a high > chance of messing up the undo stack. Such API would be useful for Basic macros also! The posted issue numbers relate to that. > So far I have glimpsed at svtools/source/undo/undo.cxx. As little as > exposing the methods of SfxUndoManager in this file would be useful (I > see a Clear method, so an extension could at least clear the undo > stack altogether instead of turning undo confusing and frustrating). Yes, that could be a start, but maybe a different approach could be more promising (please see below). > This would take care of c). I think a) is doable as well -- just > create some UndoAction that can contain other UndoActions (I see an > unimplemented Merge method, maybe it is implemented someplace else or > I could finish it). > Can you tell if b) and d) are possible? My idea for an Undo API and its implementation is the following: undo steps are created by the internal changes of the document. They are collected on the undo stack of the SfxUndoManager. The undo steps visible to the user (the whole list through the "Undo" toolbar button, the top entry in the "Edit" menu) are either one of these entries or a group of entries. Such a group can be created by opening a "context" via Undo API. A context is created by calling "startUndoContext" and providing a (localized) string that can be displayed in the GUI to represent the complete action. A following "closeUndoContext" will close the last open context. The "startUndoContext" and "endUndoContext" commands are marks on the internal Undo stack (the stack the SfxUndoManager maintains), and the GUI allows to jump between two marks, collecting several "internal" steps into one. If no undo context is open while an internal undo step is created, "automatic" contexts will be created where each context comprises a single internal undo step and its diplay title is the title of this step. That would be the default behavior as now where no "external" Undo API calls are done. To me that sounds like what you wanted to achieve with your wish d). A possible implementation of this API could be done on top of the SfxUndoManager code. It might be easier and less risky to do it that way as basically the Undo code that the document core uses remains unchanged. It will be necessary to change the UI code that uses SfxUndoManager to carry out Undo or Redo actions but I think this will be necessary in all implementations. I'm still wondering what the use case for wish b) might be. Do you think you need to be able to hide an arbitrary action? Can you explain? Or can you imagine yourself how that could fit into my "undo context" model? In case you wanted to work on that feature by yourself we would be glad to support you. There are some "formalities" we have to clarify before. Do you know http://contributing.openoffice.org/programming.html and especially the part "How to submit code to OpenOffice.org"? Best regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
