Show the picked preset's real values in the process-settings panel

The panel baselined every field on the option schema's compiled-in
defaults, so a preset setting a 0.42mm line width displayed 0 -- the C++
default meaning "derive from the nozzle". Every field was affected; the
Line width group just made it obvious.

Bambuddy cannot answer this itself. A standard-tier pick is only an
{inherits: ...} stub on our side, and local/cloud presets are deltas whose
remainder lives in the profile tree bundled inside the running sidecar.
The values now come from the sidecar's POST /profiles/resolve, which runs
the same resolver /slice does against the same profiles, so what the panel
shows cannot disagree with what a slice produces. Deliberately not the
local orca_profiles resolver: it walks OrcaSlicer's published tree, which
can differ from the image actually installed.

An untouched field shows the preset's value and reverting returns to it.
isModified compares against that baseline too, so fields the preset moved
off the C++ default are no longer flagged as user edits, and values nobody
typed are no longer sent. When the values can't be read -- sidecar offline
or older than the endpoint -- the panel falls back to schema defaults and
says so rather than presenting them as the preset's.

Row layout, from screenshots:

- The control column is anchored to the right edge at a fixed width. It
  had been packed left after a fixed label column, leaving the values
  stranded mid-container with dead space beside them.
- Units are no longer truncated to "mm o...". The cap fitted the common
  "mm" but not "mm or %" or "mm/s² or %".
- The "from file" tick moved ahead of the control it qualifies; it used to
  sit past the unit at the row's right edge, reading as unrelated.

Both the unit and the control keep fixed widths, and the tick's slot is
reserved on rows without one -- sizing any of them to content makes each
row's input land at a different x and the column comes out ragged.

Also fixes a field that could not be cleared: emptying a free-text input
dropped the key, so it snapped back to the baseline and retyping appended
to it ("0.42" + "0.5" = "0.420.5"). The number branch was fixed earlier;
the text branch -- coFloatOrPercent, coString, the vector types -- was
not, and the regression test used a number input so it never caught it.

Requires a sidecar built from orca-slicer-api 4b664b7 or later. Older
images 404 the endpoint, which is handled as the fallback above.
This commit is contained in:
maziggy
2026-08-09 11:02:03 +02:00
parent c384911f7c
commit f421bb8160
25 changed files with 536 additions and 109 deletions
+22
View File
@@ -1614,6 +1614,13 @@ export interface PresetRef {
source: PresetSource;
id: string;
}
export interface SlicerPresetValues {
/** False when the sidecar could not supply values; `values` is then empty. */
resolved: boolean;
/** Flattened key -> value map, in the string forms a process preset stores. */
values: Record<string, string | string[]>;
}
export interface SliceRequest {
printer_preset_id?: number;
process_preset_id?: number;
@@ -7260,6 +7267,21 @@ export const api = {
getSlicerPrinterModels: () =>
request<Record<string, string>>('/slicer/printer-models'),
/**
* Effective values of a process preset, with its `inherits:` chain flattened
* by the slicer sidecar. Powers the slice modal's settings panel, which would
* otherwise show the option schema's compiled-in defaults (a preset setting a
* 0.42mm line width appears as the C++ default of 0).
*
* `resolved: false` means the values could not be obtained -- sidecar offline,
* too old for the endpoint, or slicing not configured -- and the caller should
* fall back to schema defaults rather than treat it as a failure.
*/
getSlicerPresetValues: (ref: PresetRef) =>
request<SlicerPresetValues>(
`/slicer/preset-values?source=${encodeURIComponent(ref.source)}&id=${encodeURIComponent(ref.id)}`,
),
// Local Presets (OrcaSlicer imports)
getLocalPresets: () =>
request<LocalPresetsResponse>('/local-presets/'),