Re: Attempt for an UNO Undo API

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 "[email protected]".
I use it for the OOo lists and only rarely read other mails sent to it.