Opened 10 years ago

Last modified 9 years ago

#6764 new defect

Selecting anything in the vicinity of selected nodes is nearly impossible

Reported by: Daeron Owned by: team
Priority: major Milestone:
Component: Core Version:
Keywords: Cc: stoecker, bastiK, cmuelle8

Description (last modified by xeen)

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.

Attachments (1)

dilemma_fix.patch (3.7 KB) - added by xeen 10 years ago.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 10 years ago by stoecker

Owner: changed from team to xeen

comment:2 Changed 10 years ago by bastiK

Confirmed, that r4118 causes the bug.

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

comment:3 Changed 10 years ago by 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.

comment:4 Changed 10 years ago by stoecker

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

comment:5 Changed 10 years ago by xeen

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

Changed 10 years ago by xeen

Attachment: dilemma_fix.patch added

comment:6 Changed 10 years ago by xeen

Cc: stoecker bastiK added

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.

Last edited 10 years ago by xeen (previous) (diff)

comment:7 in reply to:  6 ; Changed 10 years ago by 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


comment:8 in reply to:  7 Changed 10 years ago by 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..

comment:9 Changed 9 years ago by cmuelle8

Cc: cmuelle8 added

comment:10 Changed 9 years ago by 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

Last edited 9 years ago by cmuelle8 (previous) (diff)

comment:11 Changed 9 years ago by xeen

Description: modified (diff)
Owner: changed from xeen to team

Not going to work on this any time soon.

Modify Ticket

Change Properties
Set your email in Preferences
as new The owner will remain team.
as The resolution will be set.
to The owner will be changed from team to the specified user.
The owner will change to Daeron
as duplicate The resolution will be set to duplicate.The specified ticket will be cross-referenced with this ticket
The owner will be changed from team to anonymous.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.