Skip to content

Conversation

@afrdbaig7
Copy link
Contributor

Fixes #2753.

When dragging a point and pressing Shift to constrain movement, the constraint was starting from the original drag position instead of the snapped position, which caused an unexpected jump.

This PR fixes that by locking the constraint origin when Shift is first pressed and using the snapped mouse position, so constrained movement behaves consistently even after snapping or axis changes.

The behavior when starting a drag with Shift, releasing and re-pressing Shift, and normal dragging remains unchanged. All existing tests pass.

…teEditor#2753)

When constraining movement with Shift during a drag, the constraint now starts
from the point’s snapped position rather than the original drag start. This
makes constrained movement behave more intuitively when snapping is active.

The fix keeps the constraint origin stable on the first Shift press and uses
the snapped mouse position so the origin doesn’t change during axis switches.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Path tool dragging, then pressing Shift to constrain horiz./vert., should begin from a snapping point

1 participant