When changing a clone's parent's layer, the clones shift position

Bug #1245339 reported by Formerly Kevin Yin, now disabled on 2013-10-28
This bug affects 7 people
Affects Status Importance Assigned to Milestone

Bug Description

See attached file.

1. Notice that the top object is a clone of the bottom object.
2. Select the bottom object, and press Shift+PgDn to move it into the next layer.

The top object disappears.

As a sidenote unrelated to the original bug, the description of the cloned object is a "Clone of: Group of 6 objects in layer Auxiliary". However, it's the clone that's in "Auxiliary", not the original objects. The wording is a bit confusing.

su_v (suv-lp) wrote :

Same underlying issue as e.g.
- Bug #1195043 ""move selection to layer above” spreads clones up”

The original and the clone are on different layers, one of the layer groups has a 'transform' attribute (it apparently was created before changing the document page, while the 'Auxiliary' layer was added afterwards). Moving the original group from the (transformed) layer to a layer with a different (or no) transformation causes the clone(s) to be displaced.

Workaround to move the original to the same layer as its clone (-> 'Auxiliary'):
1) Select the clone and move it to the layer of the original ('Frame Copy')
2) select clone and original, and group the selection
3) move the group to the 'Auxiliary' layer
4) ungroup

tags: added: clones groups layers transformations
su_v (suv-lp) on 2015-02-11
summary: - cloned object disappears when changing the original object's layer
+ When changing a clone's parent's layer, the clones shift position
Mc (mc...) wrote :

Fix proposed (note : part of the fix is actually the fix of https://bugs.launchpad.net/inkscape/+bug/653574 )

su_v (suv-lp) on 2015-02-12
Changed in inkscape:
assignee: nobody → Mc (mc...)
importance: Undecided → Medium
milestone: none → 0.92
status: New → In Progress
jazzynico (jazzynico) wrote :

Patch tested on Crunchbang Waldorf, Inkscape trunk rev. 13919.
The patch fixes the bug and the one reported in Bug #653574. No regression found so far.

A new version of the patch is in progress to fix some formatting and coding style errors.

Mc (mc...) wrote :

Same patch, with style corrections

Mc (mc...) wrote :

Hopefully fixed again.
The latest change solved the non-declared bug where you change the original of a clone of layer when it's in a group whose transform is not commutative with the layer's, because i messed up a non-commutative matrix multiplication (example : take an object, clone it, put the original in a group, move the group, enter the group, change the object of layer; the clone moved... Not anymore with this new patch).

Taking a paper and pen helped :) .

jazzynico (jazzynico) wrote :

Patch committed in the trunk, rev. 13924.
Thanks Mc!

Changed in inkscape:
status: In Progress → Fix Committed
su_v (suv-lp) wrote :

If possible, it would be nice to have this fix backported to 0.91.x

tags: added: backport-proposed
Marc Kruzik (marc-kruzik) wrote :

I can confirm the group-move_to_layer-ungroup trick is working (currently using v0.91).
Mc made a patch, so I'm writing this mostly for new people coming on the thread.

I found out that a new document doesn't have the bug, except if you change its dimensions:
1- new document
2- preferences > change dimensions (640 x 480 px)
3- create a new layer
4- create an object (a square)
5- clone the object
6- move both the object and its clone to the new layer (SHIFT + PgUp)
7- the clone have the wrong position
If you don't do step 2, you don't have the bug. If you do step 2, you have the bug. Note that the bug is surely also caused by other ways.

I will use the group trick until the next version. Thanks Mc for the hard work.

ScislaC (scislac) wrote :

trunk r13924 backported in 0.91.x r13763

Changed in inkscape:
milestone: 0.92 → 0.91.1
tags: removed: backport-proposed
Mc (mc...) wrote :

13924 without 13935 will introduce a performance regression, you can find attached the patch of 13935 for 0.91.x branch

su_v (suv-lp) wrote :

The changes in r13935 for trunk, and the backport if applied to 0.91.x r13765, seem to introduce a regression:

Steps to reproduce:
1) launch trunk >= r13935 (default prefs)
2) open Inkscape's 'icons.svg' file
3) select all (Ctrl+A)
4) ungroup (Ctrl+U)

Expected result:
objects stay in place

Actual result:
many objects are displaced after ungrouping

Not reproduced with 0.91+devel r13934 and unpatched 0.91.x r13765 (all tests done on OS X 10.7.5).

Mc (mc...) wrote :

Thanks for pointing this bug, this one should also correct it

su_v (suv-lp) wrote :

Wrt regression as described in comment #13
- fix for trunk was committed in revision 14084
- fix for 0.91.x (perf9.diff) successfully tested with 0.91.x r13765 on OS X 10.7.5

Resetting bug status (milestone) and tags, so that we don't forget to include the backport for 0.91.1.

Changed in inkscape:
milestone: 0.91.1 → 0.92
tags: added: backport-proposed
ScislaC (scislac) wrote :

Patch from comment #14 committed in 0.91.x r13766

Changed in inkscape:
milestone: 0.92 → 0.91.1
tags: removed: backport-proposed

Very probably the same bug? Same behavior (clone displaced when parent moved to other layer), but no groups are in play. Layers do have translates. See attached file: select upper eyelid, Shift+Pgdn -> lower eyelid (clone) is displaced.
Inkscape 0.91 r13725 on Ubuntu 16.04 LTS

jazzynico (jazzynico) on 2017-01-28
Changed in inkscape:
milestone: 0.91.1 → 0.92
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers