On Wed, Aug 10, 2005 at 03:23:02PM -0300, bulia byak wrote:
On 8/10/05, Nicklas Lindgren <nili@...612...> wrote:
By replacing the code above with a call to sp_selection_delete_impl(), the bug is fixed, but the clones become regular duplicates.
Is this desirable? Or should it be fixed in a way that preserves clone-relations? (The comment seems to indicate that this is the plan.)
Yes, the idea was to preserve the clone links as much as possible. However I still do not understand the reason for the bug. The deleteObject (false) deletes the object without notifying its clones, so they don't get the chance to realize they are orphans. Later, that same object is restored in the pattern, with the same ID, so the clones should just stay, now linked to that restored object. [...]
The problem seems to be, that they aren't restored later, but they are restored first, with the call to pattern_tile just above the mentioned code. Therefore the objects are in effect duplicated instead, and their id-attributes are changed. After that the objects with the original ids are silently deleted.
The problem is solvable by moving the deletion before the call to pattern_tile.
But this exposes another problem. A transform is applied to all objects in the pattern to anchor the top-left in 0,0. Applying a transform to a clone-original affects all the clones, and affects clones included in the pattern twice.
Should perhaps a reverse transform be applied to all the clones in this case?
An alternative that seems to be simpler is to apply x and y attributes to the newly created pattern element, rather than transforming each contained object, but this seems to make pattern-drawing buggy :-(.
--Nicklas