Id: object focus (for fields) does not switch to other object, after another object was moved

[my-na-me]

I just noticed a question for object focus while editing with iD.

For example: the focus is for the moment on a node lets say a cafe object (amenity=cafe element). There is another node which is an amenity=bench. I would like first to correct the position (lat/lon) and second to add more additional attributes for the bench object.
So I will move the bench-node and goto left window side for adding more fields, but then I see the focus is still at the cafe-node object.

Is this an intended behavior? If not. please could you change it in a way that the focus is on bench object after moving the bench-node.
(I think this can be also reproduced for osm way-elements)
.
see here:

[bhousel]

I think it has always been this way by design. This behavior is what allows you to adjust a way shape by moving its vertices. If we changed the behavior, iD would select the vertex instead of leaving the way selected.

[slhh]

When moving independent objects, the selection should be changed to the moved object. It doesn't feels intuitive to modify something which isn't selected. Selecting the moved objects can also make the user aware of an accidential drag.

When moving a vertex of a selected way, the selection should not be changed. This doesn't feel wrong, because moving the vertex means modifying the shape of the selected object.

[quincylvania]

When moving independent objects, the selection should be changed to the moved object.

This sounds okay. Other editing apps like Keynote and Sketch work like this and it feels natural.

@bhousel What do you think about doing this for points but not vertices?

[bhousel]

This sounds okay. Other editing apps like Keynote and Sketch work like this and it feels natural.

@bhousel What do you think about doing this for points but not vertices?

I agree this seems ok for points..

[my-na-me]

:-)

[slhh]

@quincylvania
Points are ok. Vertexes of a selected way need to be excluded, but we don't need to exclude vertexes at all.

When dragging a connecting vertex or a tagged vertex without selecting at least one of the parent ways first, the selection should switch to the dragged vertex.

[quincylvania]

When dragging a connecting vertex or a tagged vertex without selecting at least one of the parent ways first, the selection should switch to the dragged vertex.

I disagree, at least for untagged vertices. Dragging an untagged vertex strongly implies the user just meant to reshape the way, not inspect anything. I'm imaging the selection constantly changing while the user is aligning a road and it driving them nuts.

[slhh]

@quincylvania

I disagree, at least for untagged vertices.

We seem to be talking about different things here.
In general, an untagged vertexes needs a parent way to be selected to become dragable, so it is a vertex of a selected way, and needs to be excluded according to my previous post. Tagged vertices should be handled identically when dragged in the same member.

I do only request to change the focus in the following cases:

• Dragging a vertex (e.g. a highway connection) while something unrelated (e.g. a building) is selected.
• Dragging a vertex while nothing is selected.

Both cases are limited to connecting or tagged vertexes, because other ones aren't dragable in these cases.

As a general rule, dragging a node should always change something which is or gets selected:
This can either mean reshaping a selected way or repositioning a selected node.