On 10/22/2010 09:07 PM, Frank Schönheit wrote:
Hi Mathias,
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.
Well, one scenario Ingrid and I discussed here is the deletion of
rows/columns which are part of a source range for a chart. If this is
undone, the best chart can currently notice is the insertion of a
row/column. Whether or not this column was part of the source range is
not part of the broadcast event - not much of a chance for Chart to find
out.
This implies that chart source range handling/undo should be done in
Calc. On the other hand, this means Calc (or any application embedding
charts) needs to know pretty much details about Chart's handling of data
source ranges - imagine all the different chart types, and the degrees
of freedom you have for their defining their data sources.
Which means that extensions to the Chart core might require extensions
to the core of the embedding documents - not really desirable.
Those problems are probably solvable (and as said, we don't aim for
those solutions for 1.0), but I am not convinced it is as easy as saying
"undoing an instigating change will automatically undo the resulting
change" - simply because currently, listeners might not always transport
enough information for this.
Let me put it that way: undo actions should only record direct actions.
If changes in a component cause indirect changes elsewhere (e.g. by a
listener connection), these changes should not be recorded in an undo
action. Or the other way around: if actions in a sub component are
recorded, they should be made directly by the super component. Otherwise
you will get ugly code that always needs to know whether it is currently
in an undo action or not. This code is very prone to regressions. Been
there, done that, got to hate that.
If the information provided to a listener is not sufficient, that should
be changed.
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
