* CLI: record user overrides in different_settings_to_system for 3MF export
Three sites in CLI::run wrote an empty `different_settings_to_system` column
and left a //todo:
//todo: support user machine preset's different settings
different_settings[filament_count+1] = "";
//todo: support system process preset
different_settings[0] = "";
//todo: update different settings of filaments
different_settings[filament_index] = "";
So a 3MF exported by the CLI does not record which keys the user actually
overrode relative to the system parent. Re-opening such a project in the GUI
then shows spurious "unsaved changes", and accepting that dialog can revert
inherited process/filament/machine values to system defaults.
The column could not be filled before because the CLI had no resolved view of
the parent preset. It does now: #15438 builds a PresetBundle for inherits
resolution, so the parent can be looked up by name and diffed against the
resolved leaf. This adds no extra loading -- the bundle is the one already
built, and the helper returns "" whenever it is unavailable or the parent
cannot be found, which is the previous behaviour.
Preset metadata is filtered out of the diff: `inherits`, the three
`*_settings_id` keys, and `compatible_printers` / `compatible_prints` and
their `_condition` variants, which have their own tracking columns
(`inherits_group`, per-slot lists) and would otherwise double-count.
A value already carried by the loaded JSON still wins for the process slot, so
presets saved with a `different_settings_to_system` field behave as before;
the computed value only fills the gap where that field is absent, which is the
case for every user preset in my datadir (0 of 47 carry it).
System presets keep an empty column: there are no user overrides to record.
* CLI: diff the filament slot before load_default_gcodes_to_config
The process and machine slots compute their different_settings_to_system column
before load_default_gcodes_to_config(); the filament slot did it after. That
call materialises absent gcode keys via option(..., true), and
DynamicConfig::diff only compares keys present in both configs -- so a gcode key
the resolved leaf did not carry would go from 'not compared' to 'compared as
empty against the parent' and land in the column as an override the user never
made.
Hoisted into a local above the call, guarded by load_filament_count > 0 so the
work is skipped exactly where it was before, and assigned at the original site.
The diff now also runs before config.erase("filament_settings_id"), which is
immaterial: cli_different_settings already filters filament_settings_id along
with the other *_settings_id keys.
This is a consistency fix rather than a demonstrated defect -- resolve_preset
merges the parent config, so in practice the gcode keys are already present on
both sides and the diff is unaffected. It removes the dependence on that
invariant, which the other two slots never had.
Reported by HanifKoh in review of #15595.
CLI: guard 4 null derefs when loading a 3mf with no preset ids
At OrcaSlicer.cpp:1700-1704 the post-load block reads printer_settings_id,
print_settings_id, filament_settings_id, and nozzle_diameter from the
config that the 3mf carries. If the 3mf is a BBL/BBS-flavored 3mf but
was produced by a non-GUI writer (e.g. CLI --export-3mf without a
loaded preset) any of those keys can be absent, and config.option<T>(...)
returns nullptr — the ->value / ->values deref then SIGSEGVs.
Wrap each optional lookup in an if-let. printer_model, printer_extruder_variant,
and print_extruder_variant already pass create_if_missing=true and are safe.
Repro (BEFORE this patch):
orca-slicer --export-3mf out.3mf in.stl # produces preset-less 3mf
orca-slicer --info out.3mf # SIGSEGV at :1700
bt: __cxx11::basic_string::_M_assign
-> Slic3r::CLI::run @ OrcaSlicer.cpp:1700
AFTER: --info out.3mf returns exit 0 with the mesh summary.
The same failure mode affected --inspect-mesh, --inspect-paint, and
every other action that has to walk the loaded model's config; --slice
would only survive because it always injects a printer via
--load-settings.
OrcaSlicer currently ships an "Octo/Klipper" host type that maps to the
OctoPrint REST endpoints (api/version, api/files/local). It works for
Klipper setups that run Moonraker with the OctoPrint-emulation plugin,
but native Moonraker — and Moonraker-compatible firmwares like the
Prusa-Firmware-Buddy buddy-klipper fork — speak a different shape:
distinct paths, JSON body for /printer/print/start, {"result":...}
envelope. There's no host type for that today.
Add a new Moonraker class deriving from PrintHost. Endpoints used,
matching the Moonraker spec:
- GET /server/info — connection test, reads
result.klippy_state
- GET /server/files/roots — storage-picker dropdown
(returns roots with 'w'
permission); gracefully
degrades if absent
- POST /server/files/upload (multipart) — upload (form fields:
file, root)
- POST /printer/print/start (json) — {"filename":"<path>"}; the
filename is whatever the
upload response returned
in result.item.path, so any
server-side rename
(collision suffix etc.) is
respected. JSON body is
built via property_tree
write_json so exotic
characters in the path are
properly escaped.
Auth: X-Api-Key header, only when printhost_apikey is non-empty
(Moonraker can be configured to require it but doesn't by default).
HTTP Basic / Digest are not part of the Moonraker spec and are not
sent.
Storage root is read from upload_data.storage with "gcodes" as the
fallback default, so the existing storage-picker plumbing in
PrintHostDialogs lights up automatically once enumerable roots are
returned.
UI: registers as the "Moonraker (Klipper)" entry under host_type;
selectable via the existing Physical Printer dialog (sidebar's
connection button on the printer card).
Verified against a Prusa-Firmware-Buddy buddy-klipper fork (firmware
identifies as moonraker_version "0.8.0-prusalink-shim"): /server/info
test, multipart upload to /server/files/upload, and JSON
/printer/print/start all work end-to-end. The existing "Octo/Klipper"
entry is left untouched so users currently relying on Moonraker's
OctoPrint-emulation plugin keep working.
FlowRateCalibrationDialog was missing the SetSizeHints call that every
other calibration dialog in calib_dlg.cpp uses (Cornering, Pa, Pa Pattern,
Max Volumetric Speed, Temperature, Retraction, VFA, Input Shaping). Without
it, the dialog has no enforced minimum size: on wxGTK, iconizing the main
window while the dialog is open triggers a layout/refresh that re-runs
Fit() with transient zero-sized children, collapsing the dialog to ~222x249
px with the OK button clipped and unreachable. The window manager then
honors the (incorrect) small geometry hint, so the user cannot resize it
back manually.
Two changes:
* Add v_sizer->SetSizeHints(this) after Fit() in the constructor, matching
the pattern used by all other dialogs in this file. This locks in the
correct minimum the first time Fit() runs, before any iconize event.
* Remove the redundant Fit() from on_dpi_changed. With SetSizeHints in
place the WM enforces the minimum, but the unconditional Fit() on every
DPI/refresh signal was the trigger for the shrink path; Refresh() alone
is sufficient here.
Co-authored-by: Packerlschupfer <packerl@schupfer.at>
packerlschupfer