Auto Thread Match toggle is permanently disabled with a tooltip referencing dead issue numbers #24/#29 — the value is in state but never read, the toggle is a UI lie #145

Closed
opened 2026-10-03 04:24:12 +00:00 by Mark · 1 comment
Owner

Finding

The RightPanel's Auto-Digitize Settings section has an "Auto Thread Match" toggle (src/components/workspace/RightPanel.tsx:255-261):

<ToggleField
  label="Auto Thread Match"
  value={autoDigitizeSettings.autoThreadMatch}
  disabled
  tooltip="autoThreadMatch requires the PR10 catalog (see #24 / #29)"
  onChange={(v) => dispatch({ type: 'SET_AUTO_DIGITIZE_SETTING', key: 'autoThreadMatch', value: v })}
/>

The toggle is permanently disabled. The tooltip references issues #24 and #29 which do not exist in the current Forgejo issue tracker (the earliest issue in the repo is #76; these were old single-digit numbers from a pre-Forgejo tracking system).

The autoThreadMatch value is in the state type (src/components/workspace/types.ts:156) and in test fixtures, but it is never read anywhere outside the disabled toggle. The state is settable (the onChange would dispatch if enabled) but nothing consumes the value downstream — not the digitize-adapters, not the service, not the Bottom Thread Bar.

The user sees a labeled toggle that they cannot interact with. The label promises a feature. The tooltip explains it's not yet implemented but points to dead issue numbers.

Where

  • Toggle: src/components/workspace/RightPanel.tsx:255-261
  • State field: src/components/workspace/types.ts:156 (autoThreadMatch: boolean;)
  • Dead references in tooltip: #24 and #29
  • Consumer: none (the field is set on toggle, but toServiceSettings at src/lib/digitize-adapters.ts:38-65 does not include it in the service request)

Suggested fix shape

Two paths:

  1. Implement it. Wire the toggle through to the service. The resolveThreads endpoint (per #128, now active) returns a deltaE for each source color. When autoThreadMatch is enabled, the digitize response's color regions are passed through resolveThreads and the workspace's paletteIndexForColor uses the resolved catalog match instead of the engine-supplied hex. When disabled, the workspace uses the engine's hex as-is. The state field already exists; the wiring is in useWorkspace.ts around line 776.

  2. Remove the disabled toggle from the UI. The feature isn't shipped, the tooltip is misleading, and the dead reference to #24/#29 makes the codebase look unmaintained. If the feature isn't on the roadmap, drop the toggle, the state field, and the test fixtures that reference it.

Implementation is the better path: the infrastructure (resolveThreads, paletteIndexForColor) is in place, and the feature delivers a real product improvement (automatic catalog-aware color matching on the digitize side, in addition to the current per-region manual matching).

Severity

Medium. The user sees a labeled, disabled UI element. The tooltip text points to issue numbers that don't exist, which is a code-rot signal even if the user doesn't notice it.

Discovered by

Gap analysis (2026-10-02) of auto-digitize settings after the round 5 + #127/#130/#128 work landed.

  • #128 (closed) — wired resolveThreads into the digitize response. The autoThreadMatch toggle is the natural user-facing control for this.
  • #120 (closed) — replaced the hardcoded thread library with a CRUD library. The autoThreadMatch toggle predates #120 and references the pre-#120 PR-10 catalog concept.
## Finding The RightPanel's Auto-Digitize Settings section has an "Auto Thread Match" toggle (`src/components/workspace/RightPanel.tsx:255-261`): ```tsx <ToggleField label="Auto Thread Match" value={autoDigitizeSettings.autoThreadMatch} disabled tooltip="autoThreadMatch requires the PR10 catalog (see #24 / #29)" onChange={(v) => dispatch({ type: 'SET_AUTO_DIGITIZE_SETTING', key: 'autoThreadMatch', value: v })} /> ``` The toggle is **permanently disabled**. The tooltip references issues `#24` and `#29` which do not exist in the current Forgejo issue tracker (the earliest issue in the repo is `#76`; these were old single-digit numbers from a pre-Forgejo tracking system). The `autoThreadMatch` value is in the state type (`src/components/workspace/types.ts:156`) and in test fixtures, but it is **never read anywhere outside the disabled toggle**. The state is settable (the `onChange` would dispatch if enabled) but nothing consumes the value downstream — not the digitize-adapters, not the service, not the Bottom Thread Bar. The user sees a labeled toggle that they cannot interact with. The label promises a feature. The tooltip explains it's not yet implemented but points to dead issue numbers. ## Where - Toggle: `src/components/workspace/RightPanel.tsx:255-261` - State field: `src/components/workspace/types.ts:156` (`autoThreadMatch: boolean;`) - Dead references in tooltip: `#24` and `#29` - Consumer: none (the field is set on toggle, but `toServiceSettings` at `src/lib/digitize-adapters.ts:38-65` does not include it in the service request) ## Suggested fix shape Two paths: 1. **Implement it.** Wire the toggle through to the service. The `resolveThreads` endpoint (per #128, now active) returns a `deltaE` for each source color. When `autoThreadMatch` is enabled, the digitize response's color regions are passed through `resolveThreads` and the workspace's `paletteIndexForColor` uses the resolved catalog match instead of the engine-supplied hex. When disabled, the workspace uses the engine's hex as-is. The state field already exists; the wiring is in `useWorkspace.ts` around line 776. 2. **Remove the disabled toggle from the UI.** The feature isn't shipped, the tooltip is misleading, and the dead reference to #24/#29 makes the codebase look unmaintained. If the feature isn't on the roadmap, drop the toggle, the state field, and the test fixtures that reference it. Implementation is the better path: the infrastructure (resolveThreads, paletteIndexForColor) is in place, and the feature delivers a real product improvement (automatic catalog-aware color matching on the digitize side, in addition to the current per-region manual matching). ## Severity Medium. The user sees a labeled, disabled UI element. The tooltip text points to issue numbers that don't exist, which is a code-rot signal even if the user doesn't notice it. ## Discovered by Gap analysis (2026-10-02) of auto-digitize settings after the round 5 + #127/#130/#128 work landed. ## Related - #128 (closed) — wired `resolveThreads` into the digitize response. The `autoThreadMatch` toggle is the natural user-facing control for this. - #120 (closed) — replaced the hardcoded thread library with a CRUD library. The `autoThreadMatch` toggle predates #120 and references the pre-#120 PR-10 catalog concept.
Author
Owner

Closed by 037d0b5 (fix #145).

The Auto Thread Match toggle was a UI lie: disabled was hardcoded and the tooltip referenced dead pre-Forgejo issue numbers (#24 / #29). The state field existed but had no consumer.

This commit wires the toggle through the digitize flow:

  • RightPanel (src/components/workspace/RightPanel.tsx:319-329): removed disabled and the dead-ref tooltip. The toggle now dispatches SET_AUTO_DIGITIZE_SETTING for autoThreadMatch and the user can actually flip it.
  • useWorkspace.runAutoDigitize (src/components/workspace/useWorkspace.ts:860-918): when autoThreadMatch is on (the workspace default), after resolveThreads() returns the catalog matches, every distinct source hex is rewritten to the catalog best match on stitchObjects, colorRegions, and the resulting threadStops. The exported PES now uses real thread catalog colors. When the toggle is off, or when resolveThreads fails (network down, service 5xx), the workspace falls back to the engine-supplied hex — the prior default and the safe fallback when the catalog lookup is unavailable.
  • Tests: issue-68.test.tsx now locks in the new enabled behavior (no disabled, no #24/#29 refs, click dispatches). issue-145.test.tsx adds 5 integration cases covering: autoThreadMatch=false (no rewrite), autoThreadMatch=true rewrites stitchObjects/colorRegions/threadStops, and the safe fallback when threadMatches=null.

All 597 tests pass; typecheck and lint clean (one pre-existing warning, unrelated).

Closed by 037d0b5 (fix #145). The Auto Thread Match toggle was a UI lie: `disabled` was hardcoded and the tooltip referenced dead pre-Forgejo issue numbers (#24 / #29). The state field existed but had no consumer. This commit wires the toggle through the digitize flow: - **RightPanel (`src/components/workspace/RightPanel.tsx:319-329`)**: removed `disabled` and the dead-ref tooltip. The toggle now dispatches `SET_AUTO_DIGITIZE_SETTING` for `autoThreadMatch` and the user can actually flip it. - **`useWorkspace.runAutoDigitize` (`src/components/workspace/useWorkspace.ts:860-918`)**: when `autoThreadMatch` is on (the workspace default), after `resolveThreads()` returns the catalog matches, every distinct source hex is rewritten to the catalog best match on `stitchObjects`, `colorRegions`, and the resulting `threadStops`. The exported PES now uses real thread catalog colors. When the toggle is off, or when `resolveThreads` fails (network down, service 5xx), the workspace falls back to the engine-supplied hex — the prior default and the safe fallback when the catalog lookup is unavailable. - **Tests**: `issue-68.test.tsx` now locks in the new enabled behavior (no `disabled`, no `#24`/`#29` refs, click dispatches). `issue-145.test.tsx` adds 5 integration cases covering: `autoThreadMatch=false` (no rewrite), `autoThreadMatch=true` rewrites stitchObjects/colorRegions/threadStops, and the safe fallback when `threadMatches=null`. All 597 tests pass; typecheck and lint clean (one pre-existing warning, unrelated).
Mark closed this issue 2026-10-03 06:20:07 +00:00
Sign in to join this conversation.
No description provided.