Lock segment molding to an axis with Shift

[Chetansahney]

Closes #3760

While molding a path segment with the Path tool, holding Shift now constrains the drag to a single axis (horizontal or vertical), matching the direction-locking behavior of other drag operations in the tool.

Behavior

• Hold Shift during a segment mold to lock the movement to the dominant screen axis (whichever of X/Y the drag has travelled further along).
• Release Shift to resume free movement.
• A "Lock Direction" hint is shown in the status bar while molding.

Implementation

• mold_handle_positions gains a lock_direction flag; when set, the incoming pointer position is snapped to the grab point's x or y before the drag delta is computed, so the segment moves purely along one axis.
• The Path tool forwards the existing snap_angle (Shift) key state into the molding branch, where it was previously unused, and adds the corresponding hint.

[gemini-code-assist]

Code Review

This pull request introduces a "Lock Direction" feature when molding segments in the path tool. By holding the modifier key (Shift), the drag is constrained to the dominant screen axis (purely horizontal or vertical). Dynamic hints have also been updated to display this option. There are no review comments, so I have no feedback to provide.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[cubic-dev-ai]

No issues found across 2 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}

[0HyperCube]

The implementation in #3766 is far more complete. It features overlays so you can see where you are aligning to (in your implementation the user just has to guess). It also does not offset the cursor position in such a strange way.

[cubic-dev-ai]

1 issue found across 2 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="editor/src/messages/tool/tool_messages/path_tool.rs">

<violation number="1" location="editor/src/messages/tool/tool_messages/path_tool.rs:2139">
P2: Shift molding does not fully constrain the segment when click position differs from the curve's closest point: `mold_handle_positions` subtracts the Bezier grab point, but this projection uses cursor-down position. Project around `segment.closest_point_to_viewport()` (and use that same origin for the guide) so the constrained delta's perpendicular component is zero.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P2: Shift molding does not fully constrain the segment when click position differs from the curve's closest point: mold_handle_positions subtracts the Bezier grab point, but this projection uses cursor-down position. Project around segment.closest_point_to_viewport() (and use that same origin for the guide) so the constrained delta's perpendicular component is zero.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At editor/src/messages/tool/tool_messages/path_tool.rs, line 2139:

<comment>Shift molding does not fully constrain the segment when click position differs from the curve's closest point: `mold_handle_positions` subtracts the Bezier grab point, but this projection uses cursor-down position. Project around `segment.closest_point_to_viewport()` (and use that same origin for the guide) so the constrained delta's perpendicular component is zero.</comment>

<file context>
@@ -2131,13 +2131,32 @@ impl Fsm for PathToolFsmState {
+					// through the grab point as it does when dragging points.
+					let mouse_position = match lock_direction {
+						true => {
+							let delta = input.mouse.position - tool_data.drag_start_pos;
+							let axis = if delta.x.abs() >= delta.y.abs() { Axis::X } else { Axis::Y };
+							tool_data.snapping_axis = Some(axis);
</file context>

[Chetansahney]

@0HyperCube
Thanks for the review, and fair points on both counts. Pushed 0199339.

On the overlays: you're right that there was nothing to see. I'd missed that molding already runs inside the Dragging FSM state, which means the existing X/Y guide-line overlay just needs snapping_axis set to appear. Setting it during a mold gets the same red/green lines the tool already draws when dragging points, with no new drawing code or state. That's also what the issue asked for, so I should have gone there first.

On the cursor offset: that was a genuine bug, not just an odd choice. The constraint was snapping against bezier_point_to_viewport rather than the grab point, so pressing Shift shifted the segment by the gap between the two instead of only locking the axis. It now constrains relative to drag_start_pos, consistent with point dragging.

Also moved the constraint out of mold_handle_positions into the path tool, since the drag start isn't available in the shape editor, which drops the lock_direction parameter from that API. And cleared snapping_axis on the escape/abort path and on the early return in drag stop, both of which could otherwise leak a locked axis into the next drag.

That said, #3766 predates this by several months and covers the same issue. I'm not looking to compete with it, and I arrived at the same conclusion you'd already pointed at. If you'd rather land that one, I'm happy to close this in its favour. The two cleanup items above are independent of the feature, so I can split them into a separate PR if they're useful on their own.

cargo check, clippy, and fmt are clean. I haven't verified the guide lines visually yet.

[0HyperCube]

On the overlays: you're right that there was nothing to see.

that was a genuine bug, not just an odd choice

Sorry what? You perhaps mean that you didn't implement them? This sounds LLM generated. Note that you must not use LLM generated text for PR comments per the LLM contribution policy.

I haven't verified the guide lines visually yet.

Well it is not worth anybody reviewing the code if you haven't checked if it worked. Please set state to draft PR until you have ensured you submit code that works to the best of your knowledge.

Thanks for your contributions so far!