mirror of
https://github.com/OrcaSlicer/OrcaSlicer.git
synced 2026-09-18 22:42:37 +00:00
Tommaso BianchiandClaude Opus 5
e5659e0f0f
Rebases the in-canvas work onto cad-mainline and finishes it. The field is drawn by ImGui inside the GL canvas instead of being a borderless top-level wxFrame. WHY THE FLOATING FRAME COULD NOT BE FIXED. Whether a borderless top-level may hold the keyboard is the window manager's decision, and it differs per desktop: openbox grants it, mutter refuses it, macOS denies key status outright. Seven workarounds fought that and one cost a macOS regression. Drawn inside the canvas there is no second top-level for anyone to refuse, so the question is never asked. The field is fed exactly like every other ImGui widget in the app — GLCanvas3D::on_char -> ImGuiWrapper::update_key_data -> io.AddInputCharacter. MEASURED, on behemoth: the click-edit ladder holds 28 checks — Line, Rectangle, Circle, Slot, Polygon, Ellipse, Arc, and click-to-edit on a placed dimension label — typing with NO click into the field first, committed == typed != prefill every time, and 27 [UX] imgui_char lines showing the characters arriving. WHAT WAS ACTUALLY WRONG. Not the field. The belief that "characters never reach the ImGui InputText" came from the harness: the ladder was delivering keys with `xdotool type --window` (XSendEvent), which GTK discards, so no build of any kind could have received them. The new probe in ImGuiWrapper::update_key_data — the one place ImGui is ever handed a character — is what separated that from a real defect, and it stays, because a canvas-side probe provably cannot answer the question: GLCanvas3D::on_char is bound later than any constructor-time probe, wx runs handlers in reverse bind order, and on_char returns without Skip(), so such a probe is silent whether or not the key arrived. A day was lost reading that silence as evidence. Also drops DesignPanel's content-based forwarder and DesignCanvas::inline_type_char. They were the right rule for a field that could not be focused; with the field inside the canvas there is nothing to forward, and keeping them would have masked whether the normal path works. STILL UNVERIFIED: behaviour under mutter itself. Neither focus-stealing-prevention WM available here survives long enough to judge — metacity SEGVs ~20s in and xfwm4 dies with BadWindow on SetInputFocus, both before the sketch opens and both unrelated to this field. The design's claim is structural rather than measured: no second top-level means no focus to refuse. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011FbJKJAJxxkhDTs9XdZzKA
Design-tab scripts
Everything here supports the parametric Design tab (src/libslic3r/CAD/,
src/slic3r/GUI/CAD/). Nothing here is needed to build or run OrcaSlicer — these
are the development and verification tools for that one feature.
The verb in the name is the role:
build-… |
produce a binary |
start-… |
bring something up and leave it running |
run-… |
run a suite and report pass/fail |
check-… |
one specific assertion, usually driving a live app |
Verification
| Script | What it proves | Needs |
|---|---|---|
run-kernel-tests.sh |
The CAD kernel builds and the Catch2 [CadDocument] tags pass — every case builds a document, recomputes it and asserts on real geometry. Exit 0 is the verification contract. |
Docker only. No display. |
run-all-checks.sh |
Every check below, in one command. The gate before pushing a Design-tab change. | Docker + the GUI container |
check-sketch-engine.py |
A ladder of 2D sketches of increasing complexity, judged on loop count, closure and void attribution rather than on area. | Kernel only |
check-sketch-engine-corpus.py |
The same ladder graded against a systematic sample of real drawings instead of shapes we chose. | Kernel + corpus |
check-gui-sketching.py |
The same profiles drawn the way a person draws them — synthetic mouse gestures and typed values. | Headless GUI |
check-gui-context-menu.py |
That right-click is the pivot of the design gesture, and adapts to what was clicked. | Headless GUI |
check-mcp-sketch.py |
The sketch layer driven over the MCP socket, asserting what decides whether a profile is buildable. | Headless GUI + SNAPORCA_MCP |
run-kernel-tests.sh is the only one CI can run. The rest need a live
application with an OpenGL canvas and synthetic input, which hosted runners do not
have. The kernel suite itself is already in CI by an ordinary route: the cases are
registered in tests/libslic3r/CMakeLists.txt under if (SLIC3R_CAD), so they are
part of libslic3r_tests and run under ctest on every platform like any other
unit test. This script exists for the local loop, where it is a two-minute round
trip instead of a full application build.
Build and run
| Script | Purpose |
|---|---|
build-gui.sh |
Build the GUI binary in a throwaway container, writing into the build-cache volume the long-lived GUI container reads. |
build-gui-incremental.sh |
Incremental build against the deps-baked image, for a fast edit/compile loop. |
start-headless-gui.sh |
Bring the app up on a headless X display (Xvfb + a window manager), ready to drive or attach to over VNC. |
Two constraints that are not obvious and have each cost a session:
- Never build inside the GUI container. Its baked source tree silently reconfigures the shared build directory and this fork's targets vanish.
- A window manager is required. Without one, windows are never focused, and an unfocused GTK app ignores synthetic keys — which looks exactly like a code bug.
docs/rig_build_traps.md documents these and three more, with symptoms and exact
recovery commands. Read it before debugging a configure or link failure one of
these scripts reports.