Hi Mathias, > As the other nice improvements we can bring to extension developers > should be ready rather today than tomorrow, I would opt for a simple > implementation that does not try to use combined undo stacks from > different components. > > Being able to group actions caused by API calls that - from the POV of > the extension - should be one combined entry in the undo stack is worth > the implementation already. Whether we want to use that for combined > undo stacks also is something we should decide for "version 2.0" of the > implementation (it wouldn't influence the API, IMHO).
Ingrid and /me discussed this offline a few days ago, and we also agreed that the Undo stack combination should not be part of "version 1.0" of the API. As a sketch for the later evolution, we think that the XUndoManagerSupplier comes handy here: The chart model would be such a supplier, and for the moment, it would return an own, model-local instance of the XUndoManager. The later extension would be to let it provide the XUndoManager of the embedding document. In theory, this should be completely transparent to the client, which would simply add its actions to another instance, without actually noticing it. In practice, the concrete XUndoAction implementations of course might need to be adjusted (what if you do changes to the chart, then delete the chart, then do Undo multiple times? The chart Undo actions might have a reference to an outdated chart model then.). Also, you would not want to provide, in the menu/toolbox, Undo actions of the embedding document while the Chart is activated. Regardless of this, we agreed that in this first step, we will migrate Chart's XUndoManager to the new one, laying a common ground in all applications this way, which will also be prepared for the above-mentioned changes. Ciao Frank PS: If only a Writer developer could lend me a hand for implementing the new ::svl::IUndoManager interface on top of Writer's own home-grown Undo implementation, the whole thing would be nearly finished :) -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
