Objects directly under cursor not selectable due to "grab sensitivity" of objects higher in z-order

Bug #515997 reported by LucaDC on 2010-02-02
This bug affects 9 people
Affects Status Importance Assigned to Milestone

Bug Description

I have some problems in selecting objects.
See the attached document: selecting the red segments is very difficoult because "higher" objects around catch the mouse click. Try with a zoom of 2100%.

The point is: I understand that when selecting objects the "higher" should have precedence over underlying ones but in this case if the center of the pointer is "over a red pixel" (let me say) I definitely expect the red object to be selected.
Now it seems that the search is done starting from higher objects and the first that is found for which the mouse pointer is inside a "trim-select area" is caught, also if there is another lower object which is indeed much nearer to the pointer.


LucaDC (dicappello) wrote :
su_v (suv-lp) on 2010-02-02
tags: added: ui-selection-group-layer
Changed in inkscape:
status: New → Confirmed
marcus aurelius (adbiz) wrote :

i've noticed this problem two. but in my instance, i have a grid of vertical and horizontal lines which are separated by some distance. i can't seem to selected the one i need.

a good solution is to implement what coreldraw does. when there are overlapping objects, holding down the ctrl key and clicking cycles through the objects until the desired one is selected.

prkos (prkos) wrote :

You can cycle through z-stack of objects by holding Alt and clicking. If your Alt doesn't do that you can read in Inkscape FAQ what to do to regain the functionality.

su_v (suv-lp) wrote :

@LucaDC - have you tried to lower the "Grab sensitivity" of the mouse pointer (tooltip: "How close on the screen you need to be to an object to be able to grab it with the mouse (in screen pixels)")? In my experience selection precision has improved after lowering it from default 8px to 4px.

 Inkscape Preferences > Mouse > Grab sensitivity

tags: added: selection ui
removed: ui-selection-group-layer
LucaDC (dicappello) wrote :

That's not the way I would like this problem to be solved: it's not a matter of selection "precision". And also, the grab sensitivity should be referred to the view unit not to the document, so you should always get rid of the problem after zooming in enough, but that seems not to happen.

In any case, I could want to have a huge grab sensitivity (50 pixel): consider accessibility problems; but when I click on the screen I expect that between all (non overlapping) objects falling inside the (maybe huge) grab area, the closest to the pointer is selected, not the upper but farther, because this ends up in a non intuitive behaviour.
Another case could be if the farther has such a wide border that the pointer is over it but there's another lower level object under that's nearer (or there's an upper filled object over a lower line). In this case, of course, I expect the upper object to be selected because it's what I see under the tip of the pointer; and then the Alt key will let you access lower ones.
The case I presented is the opposite: the pointer is over a lower object but a farther (non overlapping) one gets selected.

Selection is usually done clicking the object you want selected so if there's no ambiguity (i.e. the cursor is over only one object and there are no overlaps) I expect the object I'm clicking over to be selected, no matter if there's an other one higher but farther in the grab area.
Of course this requires objects' widths and fills to be taken into considerations too.

I hope now it's clearer.

su_v (suv-lp) wrote :

Not meant to ignore your detailed clarfification, just adding an important detail you might have missed:

> And also, the grab sensitivity should be
> referred to the view unit not to the document

Please read the tooltip of the setting for 'grab sensitivity': is is referring to screen pixels, not to document units.

LucaDC (dicappello) wrote :

I know that it's referring to screen pixels (i.e. view unit) but it's just a text. In fact here is where the ambiguity comes from.
I suppose that it's not true because also after zooming in a lot, the problem does not disappear.
Maybe it's true but there is another bug masking it.

Thanks for keeping this problem alive. I was wondering if it's going to be looked at because I'm still experiencing this finding it very annoying.

su_v (suv-lp) wrote :

@LucaDC - not much I can do beyond trying to cross-link reports that will help to narrow down the issue and pinpoint any underlying (mis-)concepts in the selection algorithms. I revisited this report when sorting through a more recent 'super bug' about selection issues, which describes among others one problem with nearly the same wording: «only the topmost selected, even though cursor is above lower one» (issue 5).

Bug #671532 “Losing focus/selection”:

While in my tests the behavior is zoom-dependent, I can confirm that within the 'grab sensitivity' distance (measured in screen pixel) the top-most object seems preferred or selected with higher priority than an object right below the mouse pointer.

Since I usually have 'grab sensitivity' set to 4 px, this behavior is less noticeable to me (as well as because my documents are usually small in scale (400 x 400 px) and I got used to zoom in for precise selection ;) )

Changed in inkscape:
importance: Undecided → Medium
status: Confirmed → Triaged
LucaDC (dicappello) wrote :

I verified that I was wrong: the 'grab sensitivity' is not zoom dependent, i.e. it's always referred to screen pixels so zooming in enough lets you eventually select the object. Also, it seems that thickness and fillings are already taken into account to calculate the distance from the pointer.

While checking I thought this: when the pointer has no object (rendered) under its tip(i.e. all distances are >0), we could just select the nearest one preferring the topmost only when the distances are exaclty the same; but two objects can be at slightly different distances, being the lower the (slightly) nearer also if the zoom level doesn't show that so one would expect the topmost being selected (maybe the lower is not even visible because of the rendering).
The soultion could be to round the distances to the view pixel unit before the comparison (taking 0 if <0 considers the case 'object under the tip'), then prefer the topmost object within 1 (view) pixel margin around the pointer; in this way the final behaviour should better reflect the user impression because directly related to what is rendered on screen.
Of course, only objects within the 'grab sensitivity' parameter should be considered.
Just an idea.

EmanueleSabetta (fmuaddib) wrote :

PROBLEM: I find the CLICK+ALT option to cycle between the z-ordered objects insufficient. Often there are many objects stacked one over another with the same size, with transparency and other filters applied, and just looking at the outline is not enough to distinguish them.

SOLUTION: Add a new key combination (i.e. CLICK+ALT+Z) that allow to select the objects from a dialog box with the list of all objects found stacked under the mouse cursor. This dialog box can be called "LOCAL Z-ORDERED OBJECT LIST" or "LOCAL OBJECTS Z HIERARCHY", and it should display as a popup dialog near the point where the user clicked. When the user move the mouse on the list entries, while hovering on each object name or id it should hilight the name and at the same time displaying only the hilighted object (or group) on the Inkscape drawing, hiding all other objects (or groups) of the svg tree. This way it is possible to see what object (or group) we are selecting instead of blindly selecting an invisible shape. Then just clicking on the name on the z ordered list of stacked objects would select the object and close the dialog box. If the SHIFT or CTRL modifiers are used, the behaviour it is exactly the same. The only difference is:

- With the SHIFT modifier: all already selected objects are hidden like the others, but they are tagged in the list with a small icon indicating that they have been already selected. This way the user knows that if he click again on those objects names they will be deselected. Also when SHIFT is pressed the dialog box is not closed when the user click on an entry, but multiple selection is allowed inside the list and to close the dialog box the user should press an explicit "Close" or "X" button on the dialog box.

- With the CTRL modifier: instead of listing the groups as single entries, the dialog box lists explicitly all objects inside the groups. When the mouse goes over the listed name of an object inside a group, only the hilighted object is shown and all the other objects of the same group are hidden from the Inkscape drawing.

LucaDC (dicappello) wrote :

New duplicate report: see Bug #1679978.

Patrick Storz (ede123) on 2018-07-17
summary: - Problems selecting objects
+ Objects directly under cursor not selectable due to "grab sensitivity"
+ of objects higher in z-order
Jonathan Hofinger (jhofinger) wrote :

Hi - thanks for reporting this bug, I've manually migrated it to Inkscape's new bug tracker on GitLab, and closed it here.

Please feel free to file new bugs about the issues you're seeing at http://inkscape.org/report.

Moved to: https://gitlab.com/inkscape/inbox/issues/1494
Closed by: https://gitlab.com/jhofinger

Changed in inkscape:
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.