Selecting anything in the vicinity of selected nodes is nearly impossible

[Daeron]

r4118 broke selecting anything in the vicinity of selected nodes, this makes it very hard to change the selection when editing highly dense areas unless zooming constantly in and out.

Steps to reproduce:

1. get data that has two nodes close by
2. zoom the viewport so that they have couple of pixels between them
3. select one of them
4. click the other one

Expected result: The other node gets selected.
Actual result: The selection does not change.

[bastiK]

Confirmed, that r4118 causes the bug.

@stoecker: [4118] is your change, but xeen might be more qualified to fix this. :)

[xeen]

yea I have an idea… it involves magic determining if the user wants to do a select (in which case it should be "false") or something else (then it should be "true"). Currently working on the bugs bastiK cc'ed me, so this might take some time.

[stoecker]

Hmm, I neither remeber that change nor what lead me to do it. Strange.

[xeen]

Well, it seems like a pretty good solution to #6334 for me.

[xeen]

Fixing #6334 is more important than this bug, so reverting r4118 is not an option.

This leaves us:

• WONTFIX this bug, because close primitives can be toggled using the ALT key when clicking
• use attached patch, get highlighting definitely wrong in some cases (see comments in patch)

I'm not sure which option is best. Aside of that, the selection highlighting does not honor the ALT key, but that's bug #6766.

[cmuelle8]

Replying to xeen:

Fixing #6334 is more important than this bug, so reverting r4118 is not an option.

This leaves us:

• WONTFIX this bug, because close primitives can be toggled using the ALT key when clicking

You could make this a WILLFIX by making ALT default, and, yes, I suppose other bugs will be opened, because cycling is not perfect, but IMHO it's a step in the right direction. It

• also makes selecting overlapping ways much easier.
• frees ALT key for other purposes (and iirc there already were other uses, in different contexts)

Also, earlier views of the problem would not consider this as a bug. Sticking with the selected node was intentional, but maybe that paradigm has changed by now. The main reason for this was usability in the case a user wanted to drag an already selected node. If we selected the closest node to a click position of a dense node cluster each time a click is done, we would break this use case. Again, the characteristics of this use case are:

• user does not want to zoom in, so he tries to select the right node by clicking (as in mouseup+immediate_mousedown) into the cluster
• even though nodes are dense he visually checks his selection
• if selection is ok he can now drag it w/out worries of selecting a different node on mousedown
• this also neatly solves a special case - draging a dup node (i.e. if distance of click to both nodes of a dup node is the same and we would not prefer the selected of both, the behavior of which node is dragged is undefined)

Without patching anything, you can

• use ALT+click and repeat to cycle through close nodes
• set selectaction.cycles property in PREFS (I use this)
• deselect the selected node (use key "u" or use CTRL+click)
  • then click into the fresh, untampered node cluster

greetings

[cmuelle8]

Some more info:

• one could think that a click is different from a drag, so we can detect this and carry out separate actions

• with current usage paradigms I argue that this is not possible
  • /paradigm/: an object selected on mousedown can be immediately moved ("select+drag") (1*)

• if we already have a selection, then, on a click's mousedown, these possible actions can be carried out
  • drag what is already selected (1-in-use)
  • drag another-closer-to-click node (1-possible)
  • no drag, on mouse up select what's already selected (2-in-use)
  • no drag, on mouse up select another-closer-to-click node (2-possible)

• if we were to use (1-possible) we would give up the comfy zone around a selected node
  • if a user /actually wanted/ to drag the node selected, he could end up dragging another
  • with lots of dense nodes this would be easy to produce in error
  • not all users have laser guided mouse devices or the same precision in operating their pointing gear

• if we were to use (2-possible), leaving (1-in-use) intact, which is possible, we would
  • act on different nodes depending on the action (drag / click)
  • break the /paradigm/ - since we select the new node on mouseup, we cannot do ("select+drag")

I hope this sheds some light onto the problem..

[cmuelle8]

For clarity:

• actually, when prim cycling is done, josm does use
  • (1-in-use) if the user drags
  • (2-possible) if the user clicks near a selected node
• -> so "select+drag" is only available
  • (a) for a 'brand new' selection
  • (b) for the current selection
  • _but not_ (c) for what is about to be selected next in a cycle group, which makes (made?) sense
    • .. since there is (was?) no visual indication of what exactly is selected next
    • .. since (c) would have made (b) impossible, but (b) had visual indication (i.e. node marked red)

Another possibility that crossed my mind was

• shifting this /paradigm/. the comfy-zone might not be missed, since it is replaced by highlighting as a visual feedback. i.e. dragging-what's-highlighted instead of dragging-what's-selected might be accepted by users. but we need to do it right..
  • (1) we could shrink the snap-to-comfy-zone around nodes to a pixel (for dup nodes)
    • cycling groups would virtually only exist on dup nodes, which should be ok, since in this case highlighting does not help / give a visual feedback
    • currently a nodes snap-to-comfy-zone is also used to take away selection space from a way running nearby, so we cannot generally shrink this zone, without breaking other, useful behavior
  • (2) shrink the snap-to-comfy-zone conditionally
    • i.e. shrink it for near nodes, but not for near ways
    • maybe extend and generalize the solution that already exists for calculating whether short way segments between nodes, or the nodes themselves ought to be selected
  • (3) make ALT default
    • .. and do not wait for mouse up when cycling
    • drag what is about to be selected right away
    • this depends on highlighting
    • it'd have obscure behavior, if dup node is moved - need extra code for this

[xeen]

Not going to work on this any time soon.