#314 - Editor has no 'thickness' or 'stroke width' slider for satin paths — satin stitch width is a critical parameter (1-3mm typical), but the editor uses a fixed default, no user control - Mark/Kimi_Agent_Brother_10_Digitizing_App - cyguin git: Adlerian Hierarchical Self-Actualization Syllogism

Mark commented

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

Owner

Finding

src/components/editor/EditorRightPanel.tsx's Path Properties section has stitch type, density, but no "thickness" or "stroke width" for satin paths.

grep -rn 'satinWidth' src/components/editor/ returns 0.

Satin stitch is characterized by:

The width of the satin column (1-3 mm typical)
The density (stitches per mm)

The editor's density slider controls the second but not the first. The width is a fixed value somewhere (let me check the canvasRenderer).

A user designing a logo:

Wants the satin column to be 2mm wide
Currently: depends on the path's geometry, no user control
The user has to manually adjust the path's node positions to get the right width

The fix is a "Satin width" input for satin-type paths.

Where

Path Properties: src/components/editor/EditorRightPanel.tsx
No satin width: grep -rn 'satinWidth' src/components/editor/ returns 0
The export: src/lib/easystitch-client.ts:exportPES (might have width)

Suggested fix shape

UI: a "Satin width" slider/input when stitch type is 'satin':

{p.stitchType === 'satin' && (
  <SliderField
    label="Satin width"
    value={p.satinWidth ?? 2.0}
    onChange={(v) => onUpdateSatinWidth(p.id, v)}
    min={0.5}
    max={10}
    step={0.1}
    unit="mm"
  />
)}

Type: add satinWidth?: number to the StitchPath type.
Render: in the canvas, render the satin column at the specified width (the spacing between the two parallel stitch lines).
Export: the export service uses the satinWidth to compute the actual stitch count.
Default: 2.0mm is the typical default.

Severity

Medium. Satin width is a critical parameter. Power users with embroidery work notice.

Discovered by

Gap analysis (2026-10-02) of editor path properties.

The Path Properties section has stitch type, density. Adding satin width is a parallel field.
The export (per #129) takes the satin width as input; the editor's lack of control means it's not user-configurable.
Satin width is THE key satin parameter in embroidery software. Most editors expose it.

## Finding `src/components/editor/EditorRightPanel.tsx`'s Path Properties section has stitch type, density, but no "thickness" or "stroke width" for satin paths. `grep -rn 'satinWidth' src/components/editor/` returns 0. Satin stitch is characterized by: - The width of the satin column (1-3 mm typical) - The density (stitches per mm) The editor's density slider controls the second but not the first. The width is a fixed value somewhere (let me check the canvasRenderer). A user designing a logo: - Wants the satin column to be 2mm wide - Currently: depends on the path's geometry, no user control - The user has to manually adjust the path's node positions to get the right width The fix is a "Satin width" input for satin-type paths. ## Where - Path Properties: `src/components/editor/EditorRightPanel.tsx` - No satin width: `grep -rn 'satinWidth' src/components/editor/` returns 0 - The export: `src/lib/easystitch-client.ts:exportPES` (might have width) ## Suggested fix shape 1. **UI**: a "Satin width" slider/input when stitch type is 'satin': ```tsx {p.stitchType === 'satin' && ( <SliderField label="Satin width" value={p.satinWidth ?? 2.0} onChange={(v) => onUpdateSatinWidth(p.id, v)} min={0.5} max={10} step={0.1} unit="mm" /> )} ``` 2. **Type**: add `satinWidth?: number` to the StitchPath type. 3. **Render**: in the canvas, render the satin column at the specified width (the spacing between the two parallel stitch lines). 4. **Export**: the export service uses the `satinWidth` to compute the actual stitch count. 5. **Default**: 2.0mm is the typical default. ## Severity Medium. Satin width is a critical parameter. Power users with embroidery work notice. ## Discovered by Gap analysis (2026-10-02) of editor path properties. ## Related - The Path Properties section has stitch type, density. Adding satin width is a parallel field. - The export (per #129) takes the satin width as input; the editor's lack of control means it's not user-configurable. - Satin width is THE key satin parameter in embroidery software. Most editors expose it.

Mark added the

feature-request

triage-approved

labels

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

Mark referenced this issue

2026-10-04 03:51:23 +00:00

Editor's Path Properties has a 'Density' slider (0-1) but no 'Spacing' input (in mm) — embroidery software typically shows density as mm-spacing (e.g., 0.4mm), not as a 0-1 ratio, the units are unfamiliar to embroidery users #317

Mark referenced this issue

2026-10-04 03:51:23 +00:00

Editor has no 'pull compensation' setting per path — pull compensation is a critical embroidery parameter (compensates for thread tension), but the editor doesn't expose it #318

Mark referenced this issue

2026-10-04 03:51:42 +00:00

Editor has no 'underlay' settings per path — underlay is a critical embroidery parameter (the base layer of stitches that stabilizes the main stitches), but the editor doesn't expose it #319

Mark referenced this issue

2026-10-04 03:52:30 +00:00

Editor has no 'stroke' or 'outline' preview when hovering a path — user wanting to see the satin column at full width (vs just the centerline) has to render the design (slow) #325

Mark referenced this issue

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

Editor's Path Properties has a 'Density' slider but no 'Stitch length' field — embroidery exports typically specify stitch length in mm (e.g., 3.0 mm), the editor's 0-1 density doesn't expose this #351

Mark referenced this issue

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

Editor's Path Properties has 'Stitch type' but the 'satin' path's satin width is not visible as a number — user wanting to see the current width in mm has to navigate to a hidden setting #371

Mark referenced this issue

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

Editor's Path Properties has 'Stitch type' but the 'fill' path's fill parameters (angle, spacing) are not exposed — user with a fill path wanting to set the fill angle (e.g., 45°) has no UI #373

Mark referenced this issue

2026-10-04 04:02:01 +00:00

Editor's Path Properties has 'Stitch type' but the 'cross-stitch' type has no per-stitch size input (cross-stitch X-size) — user wanting to control the cross-stitch size has no UI #390

Mark referenced this issue

2026-10-04 04:02:19 +00:00

Editor's Path Properties has 'Stitch type' but the 'zigzag' type has no zigzag-amplitude input — user wanting to control how pronounced the zigzag is has no UI #391

Mark referenced this issue

2026-10-04 04:02:20 +00:00

Editor's Path Properties has 'Stitch type' but the 'running' type has no running-stitch-length input — user wanting to control the length of each running stitch has no UI #392

Mark referenced this issue

2026-10-04 04:13:14 +00:00

Editor's Path Properties has 'Stitch type' but the 'cross-stitch' type has no per-stitch size input (cross-stitch X-size) — user wanting to control the cross-stitch size has no UI #390

Mark referenced this issue

2026-10-04 04:13:14 +00:00

Editor's Path Properties has 'Stitch type' but the 'zigzag' type has no zigzag-amplitude input — user wanting to control how pronounced the zigzag is has no UI #391

Mark referenced this issue

2026-10-04 04:13:14 +00:00

Editor's Path Properties has 'Stitch type' but the 'running' type has no running-stitch-length input — user wanting to control the length of each running stitch has no UI #392

Mark referenced this issue from a commit

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

fix(#314): right-panel Satin width slider for satin paths

Mark commented

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

Author

Owner

Shipped as commit 59e8b24 on main (rebased onto 2e6c263).

What's in this slice:

New satinWidth?: number field on StitchPath (optional, so designs persisted before this commit still open with the 2.0 mm fallback).
EditorRightPanel renders a third slider row in Path Properties — gated on selectedPath.stitchType === 'satin'. Same ?? 2.0 fallback for legacy paths, same Mixed-(primary X.X) label + apply-to-all button as the density slider (#188 / #212), and the same live-vs-commit history split as #298 so a 0.1 mm-step drag pushes ONE history entry, not dozens.
Editor.tsx wires the three handlers (onUpdateSelectedPathSatinWidth, onCommitSelectedPathSatinWidth, onApplyToAllPathsSatinWidth). New paths get satinWidth: 2.0 by default when the user is creating a satin path; non-satin paths leave the field absent so a future type switch back to satin finds the default.
svgImport.ts stamps satinWidth: 2.0 on freshly imported SVG paths so the slider shows a non-fallback value out of the box.
6 new tests in src/components/editor/issue-314.test.tsx pin the slider rendering, the live/commit split, the satin-only gate, the back-compat path with no commit handler, and the apply-to-all wiring. npm run lint clean, npx tsc -b clean for the touched files, 237/237 editor tests pass.

What is NOT in this slice (follow-up work, not in scope of this card):

The canvas renderer (src/components/editor/canvasRenderer.ts) still draws a flat polyline at fixed stroke width — it doesn't honour satinWidth yet.
The export side (src/lib/easystitch-client.ts → easystitch-service) takes its own satinStitchSpacingMm from the engine; the per-path satinWidth isn't forwarded end-to-end yet.

Those two are bigger surfaces: the canvas side needs a real satin-column renderer (perpendicular walk), and the export side needs the service to accept a per-stitch-object width override. Filing the editor affordance + persistence layer first lets users set the value while the engine / canvas catch up.

CI status: Forgejo Actions run #7577 on 59e8b24 is queued (status: waiting, self-hosted runner appears to be unresponsive — recent runs #7576 and #292 also stuck waiting/cancelled). The push landed cleanly; the runner substrate is the blocker, not the code.

Closes #314.

Shipped as commit `59e8b24` on `main` (rebased onto `2e6c263`). What's in this slice: - New `satinWidth?: number` field on `StitchPath` (optional, so designs persisted before this commit still open with the 2.0 mm fallback). - `EditorRightPanel` renders a third slider row in Path Properties — gated on `selectedPath.stitchType === 'satin'`. Same `?? 2.0` fallback for legacy paths, same Mixed-(primary X.X) label + apply-to-all button as the density slider (#188 / #212), and the same live-vs-commit history split as #298 so a 0.1 mm-step drag pushes ONE history entry, not dozens. - `Editor.tsx` wires the three handlers (`onUpdateSelectedPathSatinWidth`, `onCommitSelectedPathSatinWidth`, `onApplyToAllPathsSatinWidth`). New paths get `satinWidth: 2.0` by default when the user is creating a satin path; non-satin paths leave the field absent so a future type switch back to satin finds the default. - `svgImport.ts` stamps `satinWidth: 2.0` on freshly imported SVG paths so the slider shows a non-fallback value out of the box. - 6 new tests in `src/components/editor/issue-314.test.tsx` pin the slider rendering, the live/commit split, the satin-only gate, the back-compat path with no commit handler, and the apply-to-all wiring. `npm run lint` clean, `npx tsc -b` clean for the touched files, 237/237 editor tests pass. What is NOT in this slice (follow-up work, not in scope of this card): - The canvas renderer (`src/components/editor/canvasRenderer.ts`) still draws a flat polyline at fixed stroke width — it doesn't honour `satinWidth` yet. - The export side (`src/lib/easystitch-client.ts` → `easystitch-service`) takes its own `satinStitchSpacingMm` from the engine; the per-path `satinWidth` isn't forwarded end-to-end yet. Those two are bigger surfaces: the canvas side needs a real satin-column renderer (perpendicular walk), and the export side needs the service to accept a per-stitch-object width override. Filing the editor affordance + persistence layer first lets users set the value while the engine / canvas catch up. CI status: Forgejo Actions run #7577 on `59e8b24` is queued (`status: waiting`, self-hosted runner appears to be unresponsive — recent runs #7576 and #292 also stuck waiting/cancelled). The push landed cleanly; the runner substrate is the blocker, not the code. Closes #314.

Mark closed this issue

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

Mark referenced this issue from a commit

2026-10-05 00:42:33 +00:00

fix(#318): editor pull-compensation input — right-panel mm offset per path

Mark referenced this issue from a commit

2026-10-05 00:42:33 +00:00

test(#319): lock down editor underlay controls — panel rendering + Editor wiring

Mark referenced this issue from a commit

2026-10-05 01:48:52 +00:00

feat(#325): editor Show Satin Preview toggle for satin column overlay

Mark referenced this issue