Hi Quentin, 

Just replying to the mail you sent me privately, I thought I would post this on 
the list.

> Group and ungroup operations doesn't work well with selective undo, how to 
> support selective undo easily on these?

Hm… which problems were you thinking of in particular? I can see a potential 
problem with selective undo of the "group" operation if the group is modified 
after being created.

i.e. supposing you have a vector document containing an array of drawing 
objects like this:

rev1: ( line1, circle1, square1, image1)

and then you group circle1 and square1:

rev2: ( line1, ( circle1, square1), image1)

and add items to group:

rev3: ( line1, ( circle1, diamond1, square1,  spiral1), image1)

Selective undo means computing "diff(rev2->rev1) merge diff(rev2->rev3)" and 
applying it to rev3. The merge code we have at the moment would probably result 
in deleting the group and restoring circle1 and square1 - so diamond1 and 
spiral1 would be lost - which is undesirable.

On one hand, IMHO this behaviour isn't actually so bad. In my limited 
experience with vector graphics, groups are immutable - so to make any changes 
to objects within the group you have to ungroup anyway. Selective undo of the 
"group"/"ungroup" operation isn't very interesting anyway, since they are 
reversible, opposite operations. 


But, looking at how to fix this is also interesting. The key is, the merge code 
would have to analyze diff(rev2->rev1) and notice that the objects being 
deleted from the group are exactly the same objects being inserted into the 
document. The merge code would replace the original diff which looks like:

 "delete circle1 from group1, delete square1 from group1, delete group1 from 
doc1, insert circle1 into doc1, insert square1 into doc1" 

and transform it into a higher-level operation:

"move entire contents of group1 (whatever they may be) to doc1, delete group1 
from doc1"

When this type of diff is merged with diff(rev2->rev3), we should be able to 
generate the desired outcome.

I had the idea of implementing this when working on the ObjectMerging merge 
code and called it "move detection", but I don't think I ever implemented it. 
One question is, would such an algorithm ever have "false positives" where it 
detects a move that wasn't intended? My hunch is it is safe to apply in general 
but I haven't thought about it carefully.


Curious if you have other cases I'm overlooking, or maybe you're thinking of 
something totally different :-).

Cheers.
Eric
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev

Reply via email to