Node edit, unexpected behavior

[cggorman (Chris)]

Not sure if this a bug, unintended operation, or user error…

LB 1.4.03 on Win10

I’m doing a bunch of image import/trace and cleaning up the vectors using node edit.

If I drag/move a node or handle, then immediately hover over another and press D to remove it, the previous node is deleted. I must first “deselect” the previous node by either clicking on the new node, hitting ESC, or similar.

I’m not sure how to “show” this behavior but it is absolutely repeatable. Are my expectations off? Given the predominant “hover” workflow with node editing, it seems counterintuitive to me that I should have to select a target node. I would expect “unclicking” or releasing the mouse button after a drag move to automatically deselect and re-enable the hover behavior.

Not a big deal. I’m friendly with the the undo shortcut. Just curious if it was me missing something or a quirk/bug.

[Dskall (D Kallenberger)]

I notice that also. I think that you don’t always hit the next node so it thinks it’s still on the other one. I’m just got used to clicking each time.

[bLouChip (Lou Cipriano)]

I agree I’ve been bit by the same quirky behavior, but have trained myself that a selection trumps a hover Thank goodness for undo.

[berainlb (PY)]

Yes. This is expected behavior and changed a couple of releases back. It basically makes node editing multi-modal. If a node or multiple nodes are selected the keyboard action will affect the selected node(s). By clicking the node to move it it’s becoming selected. You need to deselect first to get the behavior you expect.

[cggorman (Chris)]

Excellent, and makes sense in the context of multiple node selection. Thanks, PY!