Inkscape

Inconsistent selection with 'Select same' on object with clones

Bug #1409195 reported by su_v on 2015-01-10

This bug affects 2 people

Affects		Status	Importance	Assigned to	Milestone
	Inkscape	Fix Released	High	Mc	Inkscape 0.92 "0.92"

Bug Description

The new select feature 'Edit > Select Same' selects based on the computed style, thus using this command on an object which has clones selects the original as well as the clone(s). The resulting selection however appears to behave inconsistently:
- the message in the status bar doesn't mention clones (unexpected)
- moving the selection with the select tool does not translate the clones
- grouping the selection unexpectedly creates new objects (unlinked clones ?)
- applying a path operation like 'Path > Union' to the selection triggers a crash

Steps to reproduce the crash:
1) launch trunk or 0.91pre3 with default (new) prefs
2) draw a rectangle
3) clone the rectangle, move it to the side, deselect it
4) select the original object
5a) apply 'Edit > Select Same > Fill and Stroke'
6) union the resulting selection (original + clone)
--> crash

5b) shift-select the clone
6) union the resulting selection (original + clone)
--> the operation fails expectedly, as explained in the message in the status bar.

Reproduced with Inkscape 0.91pre3 r13670 and 0.91+devel r13845 on OS X 10.7.5

See original description

Tags:

Related branches

lp://staging/~inkscape.dev/inkscape/trunk

Revision history for this message

su_v (suv-lp) wrote on 2015-01-10:

1409195-bt-full-r13843-debug-osx-quartz-64bit.txt Edit (19.4 KiB, text/plain)

description:

updated

Revision history for this message

jazzynico (jazzynico) wrote on 2015-01-11:

Everything reproduced on Windows XP, Inkscape trunk rev. 13847.

Changed in inkscape:
importance:	Undecided → High
milestone:	none → 0.91.1
status:	New → Triaged

Revision history for this message

Mc (mc...) wrote on 2015-02-13:

My quick investigations :
for some reason, when using get_all_items(...), "use" elements are present (with no fill by default, of course) along with a child of their own which is a non-existing element in the tree that seems to represent the element referenced by the clone where the clone is. This pseudo-element has a fill and it is it that is "selected". Since it does not really appear to exist, moving it has no effect.
I tried to put a simple line

if(!iter->getId())iter=dynamic_cast<SPItem *>(iter->parent);

before the

matches = g_slist_prepend(matches, iter);

lines, and it does work, but i doubt this is the best way to go (not having an id being an odd way to testing pseudo-elements, there must be a good method to test it)

Revision history for this message

Mc (mc...) wrote on 2015-02-15:

1409195.patch Edit (994 bytes, text/plain)

replaced by "->cloned" which is supposed to test exactly this, and made it work recursively for clones of clones

su_v (suv-lp) on 2015-02-19

Changed in inkscape:
assignee:	nobody → Mc (mc...)
milestone:	0.91.1 → 0.92
status:	Triaged → In Progress

Revision history for this message

Mc (mc...) wrote on 2015-02-20:

1409195_2.patch Edit (8.3 KiB, text/plain)

Another patch, a bit more sophisticated

Revision history for this message

su_v (suv-lp) wrote on 2015-02-20:

Second version of patch tested successfully with 0.91+devel r13926 on OS X 10.7.5, using the basic test case from the bug description: with the second version, all 4 'Select same' methods work as expected ('Fill and Stroke', 'Fill Color', 'Stroke Color', 'Stroke Style'), and the resulting selection set indicates the correct object types in the status bar.

So far not tested with more complex file structures (nested groups, and clone levels).

Mc (mc...) on 2015-02-20