Moin,

sorry for being late. There have been a lot of mails to read in the last days. ;-)

On 15.10.2010 20:23, Ingrid Halama wrote:

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.

I'm not sure if that is a good idea.

IMHO an undo action only should record direct actions in the document core of the undo provider. If this action causes changes elsewhere (e.g. by a listener mechanism), they should not be recorded as it can be assumed that the opposite change in the core (when the undo action is executed) will cause the appropriate change in the listening component also.

Doing that differently will create such a code mess we have in the Writer core when it comes to "Undo". :-)

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 ... .

Indeed, chart actions that are recorded while the component is activated, are dangerous, as executing them later when the component is no longer active and perhaps even disposed will at least make the implementation rather tricky - if not even a disaster.

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).

Regards,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamfor...@gmx.de".
I use it for the OOo lists and only rarely read other mails sent to it.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org

Reply via email to