Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Node tool: don't select another vertex after deleting a vertex (not u…
…ser-friendly in click-click mode)
- Loading branch information
a2f0763
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still have to test but :)
a2f0763
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mhugent @3nids unfortunately this is a big step backwards. Check out http://youtu.be/iiAKI0W8mgI for a demonstration of node deletion in 2.8 vs master. In 2.8 you could select a node, and then hit the delete key multiple times to progressively delete nodes in a sequential order. Now, you can only delete a single node, then you have to manually select the next node using the mouse, hit delete, select using mouse, etc... It's a big regression and will make editing quite painful.
I think a intermediate "selected but not moving" state needs to be added. So deleting a vertex makes the next vertex selected and ready for keyboard interaction (deletion or navigation using < > ), but NOT currently being moved. If you want to move the vertex you could then manually click on it to begin the move.
a2f0763
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
exactly, I was thinking also to the "selected but not moving" and it should be synchronised with the selection model of the node table views.
Therefore deleting and browsing nodes would be quite fluent!
a2f0763
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@3nids been thinking some more about this. Now I'm wondering if click click mode for node tool isnt the right approach. Would a better solution be:
The current ux is quite weird. You have to click to select a point, and then it automatically starts moving. To type in the node table you then have to move the mouse to the table, and all this time you have the rubberband following the cursor and going all the way across to the node table.
What do you think?
a2f0763
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a2f0763
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Drag and drop prevents from using advanced digitizing. I am not in favor of having the two modes as it adds more configuration (softwares should behave the same everywhere) and it would make the code much more complex.
I am quite sure that the selection model on the table view would ease deletion and selection of nodes.
a2f0763
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@3nids I can see how that would work for geometries with a small number of vertices, but what about polygons with thousands of nodes? (That's what I usually work with). In this case you can't use the table to select as its impossible to identify which a node from thousands of coordinate pairs, so the only way to select is by clicking with the mouse. At the moment is impossible to do this without triggering the move...
a2f0763
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a2f0763
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about deselecting tools by pressing a key (e.g. escape): you press delete to delete node/nodes, then "esc" to avoid moving the current node around.
a2f0763
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's the proposed approach:
Hence: