Mark/Kimi_Agent_Brother_10_Digitizing_App

Fork 0

Editor has no 'node' input modal — user wanting to precisely set a node's (x, y) coordinates (vs dragging) has to drag and read the right panel, no in-canvas input field #311

New issue

Closed

opened 2026-10-04 03:50:03 +00:00 by Mark · 1 comment

Mark commented

2026-10-04 03:50:03 +00:00

Owner

Finding

The editor's node drag updates the node's x, y. The right panel's Node Properties section (when a node is selected) shows the coordinates. But there's no input field to type a precise value.

grep -rn 'input.*nodeCoord\|nodeCoord.*input' src/components/editor/EditorRightPanel.tsx returns 0.

A user with a path:

Wants a specific node at exactly (50, 100)
Has to drag, read the right panel, adjust, repeat
5-10 iterations to get the value right

The fix is an input field in the Node Properties section.

Where

Node Properties: src/components/editor/EditorRightPanel.tsx (per the snippet)
No input: grep -rn 'type.*number' src/components/editor/EditorRightPanel.tsx returns 0 (in the node context)

Suggested fix shape

UI: in the Node Properties section, two number inputs for x and y:

<div className="flex items-center gap-2">
  <label>X</label>
  <input
    type="number"
    step="0.1"
    value={node.x.toFixed(2)}
    onChange={(e) => onUpdateNodePosition(node.id, Number(e.target.value), node.y)}
    className="w-16 px-2 py-1 border rounded text-[11px]"
  />
  <label>Y</label>
  <input
    type="number"
    step="0.1"
    value={node.y.toFixed(2)}
    onChange={(e) => onUpdateNodePosition(node.id, node.x, Number(e.target.value))}
    className="w-16 px-2 py-1 border rounded text-[11px]"
  />
</div>

Validation: clamp the value to reasonable bounds (e.g., -100 to 100 mm). The user can type any value but extreme ones are clamped.
History: each input change is a single undoable action (per #243 — debounce the input to commit on blur or Enter, not on every keystroke).
Visual feedback: when typing, the node moves to the new position in real time.
Keyboard: the user can Tab between x and y inputs for fast entry.

Severity

Low. The user can drag. Power users with precise needs notice.

Discovered by

Gap analysis (2026-10-02) of editor node editing.

The right panel's Path Properties has the same input pattern for path position (if it's shown). The node input is the deeper level.
The measure tool (per #304) is the read-side; this is the write-side.
Figma/Illustrator have input fields for node coordinates.

## Finding The editor's node drag updates the node's `x, y`. The right panel's Node Properties section (when a node is selected) shows the coordinates. But there's no input field to type a precise value. `grep -rn 'input.*nodeCoord\|nodeCoord.*input' src/components/editor/EditorRightPanel.tsx` returns 0. A user with a path: - Wants a specific node at exactly (50, 100) - Has to drag, read the right panel, adjust, repeat - 5-10 iterations to get the value right The fix is an input field in the Node Properties section. ## Where - Node Properties: `src/components/editor/EditorRightPanel.tsx` (per the snippet) - No input: `grep -rn 'type.*number' src/components/editor/EditorRightPanel.tsx` returns 0 (in the node context) ## Suggested fix shape 1. **UI**: in the Node Properties section, two number inputs for x and y: ```tsx <div className="flex items-center gap-2"> <label>X</label> <input type="number" step="0.1" value={node.x.toFixed(2)} onChange={(e) => onUpdateNodePosition(node.id, Number(e.target.value), node.y)} className="w-16 px-2 py-1 border rounded text-[11px]" /> <label>Y</label> <input type="number" step="0.1" value={node.y.toFixed(2)} onChange={(e) => onUpdateNodePosition(node.id, node.x, Number(e.target.value))} className="w-16 px-2 py-1 border rounded text-[11px]" /> </div> ``` 2. **Validation**: clamp the value to reasonable bounds (e.g., -100 to 100 mm). The user can type any value but extreme ones are clamped. 3. **History**: each input change is a single undoable action (per #243 — debounce the input to commit on blur or Enter, not on every keystroke). 4. **Visual feedback**: when typing, the node moves to the new position in real time. 5. **Keyboard**: the user can Tab between x and y inputs for fast entry. ## Severity Low. The user can drag. Power users with precise needs notice. ## Discovered by Gap analysis (2026-10-02) of editor node editing. ## Related - The right panel's Path Properties has the same input pattern for path position (if it's shown). The node input is the deeper level. - The measure tool (per #304) is the read-side; this is the write-side. - Figma/Illustrator have input fields for node coordinates.

Mark added the

feature-request

triage-approved

labels

2026-10-04 03:50:03 +00:00

Mark referenced this issue

2026-10-04 03:53:41 +00:00

Editor's Path Properties section has no 'selected node' indicator when a single node is selected — user can't tell which node in the path is currently active (vs the others), no visual highlight #333

Mark referenced this issue

2026-10-04 03:56:29 +00:00

Editor's Path Properties has a position display but no 'x, y' input for the path — user wanting to nudge a path by exact mm has to drag, no input field #353

Mark referenced this issue

2026-10-04 03:57:02 +00:00

Editor's Path Properties has a 'Total nodes' display but no 'selected node index' / 'node N of M' — user cycling through nodes (Tab) with a 20-node path doesn't know 'I'm at node 5 of 20' #358

Mark referenced this issue

2026-10-04 03:57:16 +00:00

Editor's Node Properties section has 'X' and 'Y' displays but no 'X input' / 'Y input' to type a precise position — user wanting to nudge a node by 0.5mm has to drag (low precision) #360

Mark commented

2026-10-04 22:15:03 +00:00

Author

Owner

Closing as already-shipped — the X/Y inputs exist and work.

The finding's grep returned 0 because it was case-sensitive; the component is named NodeCoordInput (capital N). The matching line at src/components/editor/EditorRightPanel.tsx:3782 is the existing editable number input, used in the Selected Nodes section at lines 2051-2062.

Land history:

fix(#141) commit 5c6da6f — initial X/Y editable inputs in Selected Nodes (NodeCoordInput helper, blur/Enter commit, Escape revert, history push via onUpdateNodePosition).
fix(#211) commit 878e8ab — extended the same NodeCoordInput to bezier handles (CI.X/CI.Y/CO.X/CO.Y) for smooth/symmetric nodes.

Current behaviour matches the suggested fix shape:

type="number" inputs labelled X / Y in the Selected Nodes section (right panel).
Local edit buffer; commit on blur (Enter blurs), Escape reverts — single history push per entry (no per-keystroke spam).
Re-seeds from the parent state when the selection changes or a canvas drag updates the authoritative position, so typing and dragging stay in sync.
Tab moves between the two inputs.
211 EditorRightPanel tests pass, including 8 that exercise the input buffer (commit-on-blur, no-commit-on-keystroke, decimal round-trip, Escape revert, Enter commit).

If the gap analysis intended a different feature (e.g., an in-canvas overlay rather than the right-panel inputs, or fractional-step inputs with step=0.1 instead of mm integers), that's a separate request and worth a new issue with that framing. As filed, the feature already exists.

Closing as already-shipped — the X/Y inputs exist and work. The finding's grep returned 0 because it was case-sensitive; the component is named `NodeCoordInput` (capital N). The matching line at src/components/editor/EditorRightPanel.tsx:3782 is the existing editable number input, used in the Selected Nodes section at lines 2051-2062. Land history: - fix(#141) commit 5c6da6f — initial X/Y editable inputs in Selected Nodes (NodeCoordInput helper, blur/Enter commit, Escape revert, history push via onUpdateNodePosition). - fix(#211) commit 878e8ab — extended the same NodeCoordInput to bezier handles (CI.X/CI.Y/CO.X/CO.Y) for smooth/symmetric nodes. Current behaviour matches the suggested fix shape: - type="number" inputs labelled X / Y in the Selected Nodes section (right panel). - Local edit buffer; commit on blur (Enter blurs), Escape reverts — single history push per entry (no per-keystroke spam). - Re-seeds from the parent state when the selection changes or a canvas drag updates the authoritative position, so typing and dragging stay in sync. - Tab moves between the two inputs. - 211 EditorRightPanel tests pass, including 8 that exercise the input buffer (commit-on-blur, no-commit-on-keystroke, decimal round-trip, Escape revert, Enter commit). If the gap analysis intended a different feature (e.g., an in-canvas overlay rather than the right-panel inputs, or fractional-step inputs with step=0.1 instead of mm integers), that's a separate request and worth a new issue with that framing. As filed, the feature already exists.

Mark closed this issue

2026-10-04 22:15:10 +00:00