mirror of
https://github.com/OrcaSlicer/OrcaSlicer.git
synced 2026-09-27 19:01:02 +00:00
2c8296a9bc7fd4e201e04e4a9b45927817c5f7b7
100
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Tommaso Bianchi
|
4ebac62519 | Extrude accepts a negative distance, and the Bodies card gains Boolean | ||
|
Tommaso Bianchi
|
edb6aa1722 | Sync cad-mainline with upstream main and carry the value-field + rename work on top | ||
|
Tommaso Bianchi
|
31a15cc5e5 | Rename snaporca/SnapOrca to orca_cad so the OrcaSlicer PR carries no Snapmaker naming | ||
|
Tommaso BianchiandClaude Opus 5
|
498e92ee35 |
The gate covers the rounded rectangle, and stops tripping over the plug-in modal
Two harness fixes, both paid for by hours of chasing product bugs that were not there.
ROUNDED RECTANGLE. It is the shape the user reported and the gate could not reach it:
the rectangle family binds R to CornerRect and leaves the other modes in the toolbar
flyout, so the three-step Width -> Height -> Radius chain was never exercised.
rung_rounded_rect() arms it over MCP the way the offer menu does. The verb id is the
OFFER id `sk_rect_rounded` — `design_rect_rounded` is the ACTION name, run_verb
throws on it, and the tool silently stays Select; a run that misses that draws
nothing and still reaches its assertions, so the rung arms AND verifies.
THE NETWORK PLUGIN MODAL. GUI_App::post_init() re-raises "Bambu Network Plug-in
Required" from an IDLE event, after any startup sweep has closed it, and
ShowModal() runs a nested event loop: the app is alive, its window is on screen,
and the MCP socket answers nothing. That is indistinguishable from a hang and was
investigated as one, with gdb, twice — the attached stack finally read
ShowModal <- show_network_plugin_download_dialog <- post_init. Seeding
`installed_networking` false stops the whole networking path, so the dialog never
exists to be swept.
Also: check() returns its verdict, so a rung can abandon itself when a precondition
fails instead of asserting into a dead end.
38 checks hold on behemoth against
|
||
|
Tommaso BianchiandClaude Opus 5
|
1dff232f0b |
The gesture ladder stops clicking the field before it types
check-gui-sketching.py located the value field by hunting for a small top-level
window and clicked into it before typing. Both halves are now wrong, and the second
was always a problem:
- field_win() cannot find a field that is not a window any more, so every check
built on it silently became one that cannot fail. Replaced by field_open(),
which asks the app: sketch_describe's `editing` is value_field_open().
- focus_field() clicked into the field first, and its own docstring said why —
"WITHOUT THIS THE TYPED VALUE IS SILENTLY DISCARDED". That workaround is exactly
what made this suite blind to the defect the user reported: a ladder that clicks
the field first can never notice that typing WITHOUT clicking is broken. Now a
documented no-op; the field is in the canvas and the canvas has the keyboard.
Measured on behemoth against
|
||
|
Tommaso BianchiandClaude Opus 5
|
e5659e0f0f |
The value field stops being a window, and now takes what is typed
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 |
||
|
Tommaso BianchiandClaude Opus 5
|
f6c551540e |
The key tracer had been printing one letter of the answer all along
focus= in [KEYTRACE] was never a class name. GetClassName() returns const wxChar* — wchar_t* in
this build — and the line cast that to const char* and printed it with %s, so it emitted the first
byte and stopped at the padding NUL. "wxGLCanvas" came out as "w". So did "wxWindow". Every focus
reading taken from this instrument for a whole day of diagnosis was a single character, and the
one question it existed to answer — WHICH widget has the keyboard — was the one it could not
answer. Printed through wxString now, and it says focus=wxGLCanvas: the canvas does hold wx focus
while the field is open, which removes the focus hypothesis for good.
Also here, and HONESTLY LABELLED AS INCONCLUSIVE: a wxEVT_CHAR probe on the canvas. It logged
nothing (cc=0), and the tempting reading is "the characters never reach the canvas". That reading
is not available, because the probe is bound in the DesignCanvas constructor BEFORE
GLCanvas3D::bind_event_handlers(), and wx runs the most recently bound handler first —
GLCanvas3D::on_char returns without Skip() exactly when ImGui consumes a character, which is
precisely the case under test. A silent probe is therefore consistent with ImGui consuming the
keys correctly AND with them never arriving. It measures nothing. Rebind it after
bind_event_handlers(), or instrument update_key_data itself, before believing anything about it.
Writing this down rather than acting on it: I came within one commit of "fixing" a mechanism I had
inferred from an instrument that could not see it, which is the same mistake as the focus= field
above and the same mistake that cost a whole session in September.
Deployed binary restored to
|
||
|
Tommaso BianchiandClaude Opus 5
|
b45d675488 |
The frames now keep coming; the characters still do not
Third measured step, and the last one I will take without a second pair of eyes.
set_as_dirty() BEFORE Refresh(): GLCanvas3D's paint handler returns without rendering when the
canvas is not marked dirty, so the previous commit's bare Refresh() posted paint events that drew
nothing and the frames stopped anyway. With both halves the pump sustains, and the trace shows the
field holding the keyboard frame after frame:
[UX] frame want_text=1 want_kb=1 active=1 buf=158.74
[UX] frame want_text=1 want_kb=1 active=1 buf=158.74 (repeating)
STILL OPEN, and now narrowed to one question: buf never changes. ImGui owns the keyboard and our
InputText is the active item, so what is missing is upstream of ImGui — the characters are not
reaching io.AddInputCharacter at all. The next thing to MEASURE (not to change) is whether
wxEVT_CHAR arrives at the GL canvas in the Design tab: DesignPanel's wxEVT_CHAR_HOOK Skips digits
while inline_busy(), but Skip only helps if the focused widget is the canvas, and nothing has yet
proved that it is at the moment the keys are sent.
Three attempts have now gone into this one point. Per the standing rule that is where solo
iteration stops.
Deployed binary restored to
|
||
|
Tommaso BianchiandClaude Opus 5
|
d82c8b59c2 |
The field now owns the keyboard; what it does not yet own is the characters
Measured, not reasoned. A per-frame trace of the ImGui state is what finally named the mechanism,
and it is a deadlock, not a focus problem:
[UX] frame want_text=0 want_kb=0 active=0 buf=158.74 <- frame 1: the widget is not active yet
[UX] frame want_text=0 want_kb=0 active=1 buf=158.74 <- frame 2: now it is
(nothing further) <- and the canvas stops
This canvas repaints ON DEMAND. ImGui decides whether it wants the keyboard at the END of a frame,
from the active item; GLCanvas3D::on_char only calls render() when update_key_data() says ImGui
wants it. So: no frames -> WantTextInput never turns on -> no render on a keystroke -> still no
frames. The characters sit in ImGui's input queue and the field is exactly as deaf as the window
it replaced, for a completely different reason.
request_frame breaks the circle, and the same trace says so:
[UX] frame want_text=1 want_kb=1 active=1
That is the first time in this file's history that the value field has owned the keyboard without
asking a window manager for it.
STILL OPEN: the typed characters do not reach the buffer (buf stays at the prefill) and the frames
stop after nine. The pump is the suspect — on software GL request_repaint() calls m_canvas->render()
SYNCHRONOUSLY, so this asks for a render from inside a render; it needs to schedule one instead.
That is the next thing to measure, not to guess.
The deployed binary on behemoth is restored to
|
||
|
Tommaso BianchiandClaude Opus 5
|
5ab3072b9f |
WIP: the value field stops being a window — renders in-canvas, does not yet take keys
The decision (Tommaso's, put to him with the trade-offs): the field stops being a separate top-level window, because whether such a window may receive typing is the window manager's call and not ours. openbox grants it, mutter on his desktop refuses, and seven previous workarounds fought that — one of them causing a macOS regression, and the test harness ending up clicking the field before typing, which is a workaround no user can be asked to perform and is exactly the "label value not editable" report. DONE and proved on the rig: SketchInlineEditor is no longer a wxFrame + wxTextCtrl. It is state plus an ImGui overlay drawn by DesignSketchTool::render(), at the same screen anchor, in the same vocabulary as the dimension labels next to it (draw_dim_label is already an ImGui window). The field opens where it should — [UX] open title=Length prefill=158.74 from the running app. NOT DONE: typing does not reach it. ImGui is fed from GLCanvas3D's own key handler, so the keys have to arrive at the canvas; giving the canvas wx focus when the field opens was not enough. The remaining question is where a keystroke goes between DesignPanel's wxEVT_CHAR_HOOK and GLCanvas3D::on_char in the Design tab, and whether the canvas repaints often enough for ImGui to advance its input state. That is attempt three on this specific point, so it goes to a second opinion rather than a third guess. Also here: scripts/CAD/check-gui-click-edit.py, the ladder Tommaso asked for. It types into the field WITHOUT clicking it first — the click is what check-gui-sketching.py's focus_field() does and why that suite can never see this defect — and fails when the prefill is what gets committed. It currently fails, correctly, on the above. Not on cad-mainline: the deployed binary must stay the last good build until typing works. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011FbJKJAJxxkhDTs9XdZzKA |
||
|
Tommaso BianchiandClaude Opus 5
|
0fee4494e2 |
Never ask for activation with timestamp 0
present_toplevel() already asked for focus with a server timestamp, but only when
the widget happened to be realized. An unrealized widget has no GdkWindow, so
there was nothing to read a timestamp from and control fell through to
wxFrame::Raise() — which asks for activation with GDK_CURRENT_TIME, i.e. 0.
Zero is exactly what focus-stealing prevention discards. metacity says it out loud
when a sketch value field opens:
Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0
and mutter, same lineage, refuses it silently on the user's desktop. That refusal
is the reported defect: the field is visible, never receives the keyboard, and
Enter commits the as-drawn prefill.
So realize the widget and retry, and do NOT fall back to Raise() on X11 — a
timestamp-0 activation is refused anyway, and on some window managers it only
marks the window as demanding attention.
Not yet confirmed end to end: both window managers with focus-stealing prevention
available here abort on this frame — metacity at frames.c:1239, xfwm4 with
BadWindow on SetInputFocus as the frame is destroyed under it — so the ladder
cannot yet return a trustworthy verdict under one. Two WMs crashing on the same
borderless, repeatedly re-mapped STAY_ON_TOP frame is its own signal about this
design. Tracked in projects-1p5 and projects-40m.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011FbJKJAJxxkhDTs9XdZzKA
|
||
|
Tommaso BianchiandClaude Opus 5
|
9134299233 |
Sketch value fields: content-based key arbiter + the gate that can judge it
The reported defect: sketch dimension labels are "not editable" — you draw a
rectangle, its Width field opens, you type, and the as-drawn number is committed
instead. It affects every sketch tool, not just the rounded rectangle.
WHAT THIS ADDS
1. The arbiter (DesignPanel CHAR_HOOK -> DesignCanvas::inline_type_char ->
SketchInlineEditor::type_char). Routes a key by what it IS, not by who the
window manager focused: digits, sign, decimal separator and Backspace/Delete
go to the open value field, Enter/Tab commit, letters stay tool shortcuts.
This is FreeCAD Sketcher's rule (DrawSketchKeyboardManager::
detectKeyboardEventHandlingMode), and the reason its sketcher behaves the same
on every desktop: it never asks who has focus.
2. The [UX] trace (SNAPORCA_UXTRACE) in SketchInlineEditor: open/commit/refused/
cancel, with the prefill and what the control actually held at Enter. It did
not exist — the ladder below was written against a surface no build emitted,
so it could only ever report "nothing opened". typed == prefill on a commit is
the defect's signature and nothing else makes it visible.
3. A draw-then-edit trace in DesignSketchTool: four early returns can swallow the
value-field chain and from outside they are indistinguishable.
4. scripts/CAD/check-gui-click-edit.py — types WITHOUT clicking the field, as a
person does, across Line/Rectangle/Circle/Slot/Polygon/Ellipse/Arc plus label
click-to-edit, and asserts committed == typed != prefill.
5. scripts/CAD/focus-loop.sh — sync/build/assert on behemoth. NOT the orcacad-gui
rig: its image pins deps 216 non-CAD files behind cad-mainline, so today's CAD
sources cannot build there without a deps rebuild.
WHAT IS PROVEN, AND WHAT IS NOT
Green under openbox: 28 checks, every tool, committed == typed != prefill.
But openbox CANNOT adjudicate this bug and the ladder says so in place. There the
field always wins the keyboard, so the same ladder also passes against a binary
with the arbiter compiled out — measured twice. Two ways of removing the keyboard
were tried and both are recorded as dead ends: XSetInputFocus loses to the field's
own re-focus CallAfter, and XSendEvent (xdotool --window) is dropped by GTK, which
made every run red regardless of the code.
Under metacity — same focus-stealing-prevention lineage as the user's mutter — the
mechanism appears in the WM's own log:
Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0
That is the activation being refused, which is exactly the reported symptom.
present_toplevel() already asks for a server timestamp, so a path is still falling
through to frame->Raise(), which sends time 0. That is the next thing to fix, and
it is tracked; the arbiter alone does not close it. metacity also aborts on this
window (frames.c:1239), so the gate needs a WM that survives before it can return
a verdict.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011FbJKJAJxxkhDTs9XdZzKA
|
||
|
Tommaso BianchiandClaude Opus 5
|
af4bbe0217 |
A shape you selected whole had nothing left to click
"Still cannot edit labels in rounded rectangles." Reproduced on the rig in a few minutes, and it
is NOT the window-manager defect the rest of this week has been about — it happens on openbox,
where typing into a value field works perfectly. The value was never the problem. The LABEL was
not there.
render_live_quotes picks the entity to speak for like this:
else if (m_selection.size() == 1) ei = m_selection[0];
if (ei < 0 || ...) return;
A rounded rectangle is EIGHT entities — four lines and four arcs — so selecting the shape makes
m_selection.size() == 8 and the pass returns before drawing anything. Its Width, Height and fillet
Radius are live labels and nothing else, so with them gone there is no affordance at all: no
number to click, no field to open, no value to refuse. The rule hid the characteristic quotes for
precisely the shapes that have nothing but characteristic quotes.
A plain rectangle looked fine only by accident. Typing into its auto-edit chain creates a DRIVEN
dimension, which render_dimensions draws from the annotation list, so its labels survive. The
rounded rect's W/H/R go through set_rounded_rect, which rebuilds the geometry and leaves no
annotation behind. Same for slot, arc-slot and polygon: every grouped feature was in this hole.
A selection that is entirely ONE feature now speaks through any member. The switch below already
keys off feature_of(ei) rather than the entity, so nothing else had to change.
Measured on behemoth :10, before and after, same binary path:
before 8 selected -> no labels at all
after 8 selected -> R26.6 / 117.4 / 150.7 drawn; clicking R26.6 opens Radius prefilled 26.60;
typing 8 gives R8.0 mm and visibly sharper corners.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011FbJKJAJxxkhDTs9XdZzKA
|
||
|
Tommaso BianchiandClaude Opus 5
|
00d6c191dc |
The chip in the corner was holding the keyboard, and the planes were holding the bed
Two reports, three defects, all three measured on the running app rather than reasoned about.
"Keyboard focus in drawing tool is broken so that now they are slow and cumbersome." After a
dimensioned entity the bottom-right readout chip — 119x31, borderless, a wxFrame — held the X
input focus. Pressing r produced NO [KEYTRACE] line at all: the key never reached the panel's
CHAR_HOOK. One bare canvas click moved focus back to the main window and the identical key armed
the tool. So every shortcut was dead after every dimension, and the way to get the keyboard back
was to click somewhere harmless. That is the whole of "slow and cumbersome".
Its sibling, the status chip, is a wxPopupWindow for exactly this reason and carries a comment
warning against turning it back into a frame. The readout was left a frame on the premise that
"it appears mid-gesture and the next input is the mouse" — which the measurement falsifies: the
chip keeps the last value on screen after the gesture ends, and a frame that has the focus does
not give it back. It is now a popup too, with the placement and the iconise/deactivate lifecycle
its sibling already needed, because an override-redirect window would otherwise sit on the bare
desktop when the app is minimised.
"Planes hide the bed." Literally true, twice over. The reference planes were half-extent 0.6 *
the bed's larger side — a square 1.2x the plate — and all three are drawn with depth testing
off, so they painted over the plate grid from edge to edge. 0.3 puts them inside the bed, which
is also the Onshape look the size was reaching for: a modest square at the origin, not a
tablecloth.
And the other half was mine.
|
||
|
Tommaso BianchiandClaude Opus 5
|
cf444a6ab6 |
A field that is logically closed can still be eating every key
Measured on the running app, not deduced. After a queued dimension chain the value field's frame is left MAPPED on purpose (mutter refuses keyboard focus to a re-mapped window), so there is a window in which m_open is already false and the frame is still on screen holding the X input focus. GTK meanwhile reports that window inactive and routes nothing into the text control. Every key then lands somewhere that cannot use it and will not give it back: [KEYTRACE] key=27 ui_mode=1 inline_busy=0 <- the last key the panel ever sees === MARK press Delete === <- no trace line at all xdotool getwindowfocus -> 0xe00404 86x60 <- the value field, still mapped Delete, Esc and typing all read as dead, which is exactly the report. And nothing could recover it: close(), cancel() and do_cancel() all return early on !m_open, so the one window still receiving keystrokes was also the one window no code could dismiss. is_mapped() asks the question the flag cannot answer, and dismiss() tears the frame down with no m_open guard, since m_open is precisely what lies in this state. Esc inside the field falls back to it — while the frame holds focus that handler is the only code the keyboard can still reach, so if it refuses, nothing else gets a turn. Every close now hands focus back to the canvas explicitly, because hiding a window does not move the X input focus off it. And inline_busy() reports the union of "a value is pending" and "a frame is mapped", so Esc routes to the field whenever one is on screen at all. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011FbJKJAJxxkhDTs9XdZzKA |
||
|
Tommaso BianchiandClaude Opus 5
|
3f52166e32 |
A sketch should not look like plate preparation
Three cues, because one is missed. A teal banner across the top of the viewport names the session
("Editing: Sketch N") and where its exits are; the printer bed is muted for the duration, since a
plate grid and a sketch grid are the same visual language and reading one as the other is how a
sketch gets drawn against the wrong reference; and N looks straight down the plane normal at the
current zoom, with the plane's own y axis as up, because no hand-orbit lands exactly square and a
sketch read at an angle is one whose right angles do not look like right angles.
The banner is an INDICATOR. Finish and Cancel stay on the single ribbon action bar — the tab had
three competing confirm surfaces once and that is not being reopened for a strip of colour. It
sits above the canvas rather than floating inside it: a child window over a wxGLCanvas is a native
window on GTK with no reliable stacking over GL, and being unmissable beats being clever.
The bed checkbox stays the stored preference and is restored on leaving the sketch; ticking it
mid-sketch still shows the bed, because that is a deliberate act and this is only a default.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011FbJKJAJxxkhDTs9XdZzKA
|
||
|
Tommaso BianchiandClaude Opus 5
|
324b558747 |
Esc is the safe key again: one press, one level, nothing destroyed
Two presses used to discard a live sketch. The key was answered in four places that could not see each other — the inline value field, a sketch branch, a feature-card branch, and the canvas — so a press aimed at one fell through to the next, and request_exit() carried a fourth layer that deliberately let the SECOND consecutive press through to cancel_sketch(). The warning it showed first did not help: the two presses are never one decision, the first is aimed at a field or a tool and the second at whatever was underneath it. The stack is now explicit. CadLevel (DesignInteraction.hpp) is four levels deep, the enum value IS the LIFO depth, and cad_escape_level() is a constexpr function over a POD of four booleans — so the ordering that is the entire contract is checked by static_assert at compile time, with no window, GL context or event loop. DesignPanel::escape() acts on the one level escape_level() names and on no other, and every Esc in the tab routes through it. The destructive layer is gone from request_exit() itself rather than guarded at its callers, so the guarantee cannot be re-opened by adding a route: a session holding geometry is left only through Finish (keep) or Cancel (discard). Cancel now asks before discarding — it used to refuse and tell the user to press the button they had just pressed, which meant a drawn sketch could be kept but never thrown away. Right-click also stops rewarding navigation with a menu: the offer needs BOTH budgets, released within 200 ms and moved no more than 3 px, and the raycast uses the press position, so the menu describes what was pointed at rather than where the camera stopped. Two budgets because drift alone still popped a menu at the end of a slow, careful orbit. docs/ux/interaction-model.md carries the state machine, the routing and the transition table. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011FbJKJAJxxkhDTs9XdZzKA |
||
|
Tommaso BianchiandClaude Opus 5
|
bb6a1810f6 |
A stray click must not break a model that looks perfect on screen
Revolve failed on a sketch whose profile was closed. Decoding the reported 3mf: four
entities forming a proper closed loop (joints open by 4.44e-06 mm, well inside
tolerance) plus one stray 1.82 mm Line at (-24.2, 80.3), inside the shaded region,
touching nothing.
The viewport's region_loops discards open chains ON PURPOSE — it exists to find
EXTRUDABLE regions — so the user saw one clean closed region. entities_to_wires kept
the stray as its own one-edge loop, so it returned two wires, and Revolve goes through
entities_to_wire which demands exactly one. Extrude would have failed one step later in
wires_to_face, because a one-edge open wire bounds no face. Same class as the tolerance
split fixed in
|
||
|
Tommaso BianchiandClaude Opus 5
|
8b568b7b9d |
The viewport and the kernel now answer "is this joint closed?" with one number
Tommaso asked the question that names the real defect: if the sketch was open, why was the same sketch shaded closed and offered for extrude? Because the two halves used different tolerances. region_loops shades a region closed at 1e-3 mm; connected_loop chained at 1e-3; the kernel welded at 1e-4 and OCCT matched vertices at 1e-7. The 2.28e-5 mm gap in the reported sketch did not cause that disagreement, it only made it visible — and fixing the gap alone would have left the contradiction in place, ready to reappear anywhere in (1e-4, 1e-3]. kSketchJoinTol now lives in SketchEngine.hpp and is the only place the number exists. region_loops, loop_report, connected_loop and entities_to_wires all read it through sketch_join_tol(). The viewport cannot promise a region the kernel refuses to build. The welding is optional, because a kernel that silently closes loops should let you say no: "Auto-close sketch loops" in Preferences, default ON, no restart. OFF means only exactly coincident endpoints join — and since both halves read the same value, the viewport simply stops shading the region closed, so an open loop is visible rather than welded behind your back. No separate UI needed for that; it falls out of sharing one number. Details that matter. The kernel defaults to auto-close ON independently of the GUI, so headless and MCP callers behave like the viewport instead of inheriting an unset preference. With the tolerance at 0 the comparisons become <=, because OFF must mean exact, not broken. OCCT never receives a zero vertex tolerance — it is clamped to Precision::Confusion. The preference is pushed from EVERY entry that starts a sketch session, not just begin(): a Constrain session enters through begin_constrain / begin_constrain_entities and uses region_loops and connected_loop, so a single push site would have left those sessions running on whatever the previous one set. begin_imported_transform is excluded deliberately — it works on imported regions, not chained entities. Tests: a loop with one joint open by 9e-4 mm, given out of traversal order, builds a closed four-edge wire; with auto-close off the same loop yields no wire; and an exactly closed loop still builds with auto-close off, proving OFF means exact. Kernel 66104 assertions / 606 cases green. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011FbJKJAJxxkhDTs9XdZzKA |
||
|
Tommaso BianchiandClaude Opus 5
|
faf4406f89 |
A wire that lost two edges still called itself done
An extrude built a solid the user never drew: three sides of the handle plus the arc
that bulges outside the outline, with the bowl's second arc and the left edge missing.
Two faults met. entities_to_wires added edges in ENTITY-CREATION order, so a partial
wire rejects the next edge even when the sketch closes perfectly; and one joint of the
reported sketch is open by 2.28e-5 mm, wider than OCCT's 1e-7 vertex tolerance and
wider than this function's own EPS of 1e-6, so that edge was refused on geometry too.
Neither showed up, because BRepLib_MakeWire::Add DROPS a disconnected edge
(BRepLib_DisconnectedWire + NotDone) while every successful Add ends with
BRepLib_WireDone + Done() — overwriting the failure. `if (!wm.IsDone()) return {}`
was therefore asking only whether the LAST edge connected. Six edges in, four out,
IsDone() true.
Endpoints now weld into shared nodes at one tolerance (kSketchWeldTol) used by BOTH
the union-find grouping and the wire build — they disagreed before, which is how a
joint gets united into a loop and then refused by the builder. Each node becomes ONE
TopoDS_Vertex, so the builder matches on identity instead of proximity, with the
vertex tolerance widened because BRepLib_MakeEdge::Init projects a vertex onto the
curve within that tolerance and a welded node sits up to the weld gap off its
neighbour's curve. Members are then walked in traversal order. Finally the result is
counted: IsDone() alone is not evidence, edge_count == members.size() is.
Arc geometry is untouched — the midpoint from (start_angle+end_angle)/2 and the
solver's angle reflow both measured correct and were never part of this.
The regression case carries the reported sketch verbatim, open joint included. It
fails 4 == 6 without the fix, which was measured, not assumed. Kernel 66092
assertions / 604 cases green.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011FbJKJAJxxkhDTs9XdZzKA
|
||
|
Tommaso BianchiandClaude Opus 5
|
9858080aa0 |
The constraint list follows you into a live sketch
The rows, their ✗ buttons and the click-to-highlight were all built against m_doc.features[m_constrain_feat].entity_constraints — a COMMITTED feature. A live sketch has no committed feature, so the card was hidden for the whole session and the list it would have shown was empty by construction. Every constraint applied while drawing was nameless: the badge said one existed, nothing said which. rebuild_constraint_list now picks its source by scope. live_constraint_scope() is the same discriminator apply_constraint already used to route to apply_live_constraint — both Constrain modes set m_active, so is_sketching() alone would claim the live scope while the committed manager is open. delete_constraint and highlight_constraint_entities branch on it too, and the card shows in Sketch mode as well as Constrain. Keeping the rows in step needed a signal that did not exist: on_solve_state fires on every frame of a drag, so rebuilding from it would rebuild the list continuously. The tool now fires on_constraints_changed only when the constraint SET changes — one added by try_add_constraints, one removed by remove_constraint (the indexed form the badge click and the ✗ row now share). The rebuild is deferred through CallAfter. One of its callers is the ✗ button's own click handler, and rebuild_constraint_list destroys those buttons: deleting the window whose handler is still on the stack is a use-after-free. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011FbJKJAJxxkhDTs9XdZzKA |
||
|
Tommaso BianchiandClaude Opus 5
|
b250a2b858 |
Tell the user the badge is a button, and refresh the DoF when one is deleted
A glyph reads as decoration until something says otherwise, so the badges shipped
last commit were discoverable only by accident. Two places now say it, chosen because
they are where the eye already is:
- the moment of applying, which is the one the user is watching ("Applied constraint ·
its badge is on the sketch — click the badge to remove it"). The hint line could not
carry this alone: it only refreshes when the (mode, step, picks) tuple changes, and
applying a constraint changes none of them.
- the Select-mode hint line, appended only while the live sketch actually holds a
constraint, so it never advertises a badge that is not on screen.
Also fixes what the previous commit got wrong: remove_constraint_near solved through
solve_sketch_entities directly, which relaxes the geometry but leaves m_dof and the
per-entity conflict flags untouched and never fires on_solve_state. Deleting a
constraint therefore left the DoF readout describing the system as it was BEFORE the
deletion, and any red over-constrained tint stranded on screen. It goes through
resolve_live() now, the same path every other live edit uses.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011FbJKJAJxxkhDTs9XdZzKA
|
||
|
Tommaso BianchiandClaude Opus 5
|
3da0af38c3 |
Constraints you apply while sketching are finally visible, and clicking one removes it
The constraint badges existed and had never once been drawn where they were needed. build_constraint_glyphs read m_constrain_cons, a vector only the COMMITTED-feature Constrain mode fills, and the draw call sat inside `if (m_mode == Mode::Constrain)`. Every constraint applied during a live sketch — which is the path the Constrain buttons take while drawing, the one added in "Constrain while you sketch" — went into m_constraints and was rendered by nothing. You could not see that Parallel had applied, so "nothing happens" was indistinguishable from "applied and invisible". The glyph builder now takes its constraint list as a parameter: Constrain mode passes m_constrain_cons as before, the live session passes its own m_constraints. Same glyphs, same teal. Seeing them is half of it. A constraint's entire state is exists / does not exist, so the toggle is a delete, and there was no way to reach one during a session — the ✗ rows in the panel list are bound to the committed feature. Each badge now records where it landed (m_glyph_hits) and a plain left click in Select mode within its cell drops that constraint and re-solves. Shift/Ctrl clicks are left alone so multi-select still works. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011FbJKJAJxxkhDTs9XdZzKA |
||
|
Tommaso BianchiandClaude Opus 5
|
ea32f8dc2f |
A selected sketch line stops being white, and a refused constraint says why
Two reports, one root: the sketch tab could not show what was selected. The bed grid landed last commit, and selection was painted pure white — a freshly drawn line is auto-selected by the creation tool, so the first thing a new line did was disappear into the grid. Selection now wears design_selection_color(), the same cyan a picked solid already wears. White is kept for the hover handle alone. That invisibility is also why "I apply Parallel and NOTHING HAPPENS": drawing two lines leaves exactly ONE selected (the last), Parallel needs two, so the planner correctly refused — but the status text named only the requirement, never the current pick, which reads as a dead button. It now reports how many are selected and how to pick the second. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011FbJKJAJxxkhDTs9XdZzKA |
||
|
Tommaso Bianchi
|
741682f874 |
The Design tab gets a grid a modeller can read, centred on the origin
In CAD the centre IS the sketch origin -- GLCanvas3D already moves the axis
triad there for exactly that reason. The grid under it did not agree: it comes
from PartPlate::calc_gridlines, generated from m_origin, the plate's front-left
corner, with an adaptive step meant for a print bed.
Measured on a screenshot from the user's machine: the nearest grid line was 10 px
from the origin in a 23 px pitch. The origin floated mid-cell, in both axes.
Corner-origin is CORRECT for Prepare -- a print bed starts at a corner -- and the
plate list is SHARED with the plater, so re-centring it there would change the
bed for every user of the app to fix one tab. The seam used instead already
existed: _render_platelist takes show_grid, and m_axes_at_bed_center is already
the "this is the Design canvas" flag. The Design canvas suppresses the plate's
grid and draws its own.
Minor every 10 mm, major every 50 mm, both generated from bed_center() so a line
passes exactly THROUGH the origin in each axis. Two GLModels, rebuilt only when
the bed shape changes, not per frame.
White majors, grey minors, the SAME in both themes. There is no white bed to
vanish against: the plate is dark grey either way (DEFAULT_MODEL_COLOR
{0.326,0.337,0.337} light, DEFAULT_MODEL_COLOR_DARK {0.255,0.255,0.283} dark),
a difference of 0.07. An earlier draft inverted the palette on the light theme;
that was a branch buying nothing. For contrast with what this replaces: the
plate's grid draws BOTH its thin and bold families in one 0.43 grey, which is
most of why the stock grid reads as a flat mesh with no scale to it.
z = -0.26, the same value as PartPlate::GROUND_Z_GRIDLINE -- below the bed fill
at -0.03, above the bed model at -0.41, so no z-fighting. Matched by
construction, since that constant is file-static in another TU.
Known limit, commented: the grid is clipped to the bed's BOUNDING BOX, not its
polygon. Identical on a rectangular bed; on a circular one it would spill past
the round edge. The target printers are rectangular.
Verified on the rig, not just compiled: white majors over a fine grey mesh, and
a white line through the origin in both axes.
snaporca-kha0
|
||
|
Tommaso Bianchi
|
8b9ff36685 |
The eleven constraint buttons no rung had ever pressed
Twenty buttons on the CONSTRAIN bar, nine of them exercised. The other eleven were "implemented" in the sense that the kernel builds the right def for them -- which is exactly what was true of Parallel yesterday morning, right up until a user pressed it and got nothing. What a kernel test cannot see is whether the BUTTON is wired to the index its name claims. CON_BTN is 449 + 42*i over a hand-written name list, and it has drifted once already: six buttons were inserted, everything from index 6 on pointed at the wrong control, and nothing caught it for months because no rung pressed past index 5. D13 presses index 6; D14 through D22 press 8 to 19. The map turned out to be intact, which is worth knowing rather than assuming. D12 vertical, D13 equal_radius (its own button, not Equal's promotion), D14 concentric, D15 tangent, D16 midpoint, D17 symmetric (the three-pick form), D18 sym_h, D19 radius, D20 diameter, D21 fix, D22 dist_y. Three are shaped around a specific way the code could be wrong rather than around "does something happen": D20 exists for a factor of two. Diameter wired to the Radius handler gives r = 30 for a typed 30, and nothing on screen looks wrong. D21 -- Fix alone is unfalsifiable: nothing moved, so nothing proves the constraint exists. It only becomes observable when a SECOND constraint would otherwise move the fixed point, so the rung drives the pair to a 70 mm gap and checks which end travels. D14 asserts the radii did NOT change. Concentric is about centres; a solve that also equalised the radii would pass a naive check. D17 failed on its first run and the rung was wrong, not the app: all three entities are free, so the solver is entitled to satisfy the mirror by moving the AXIS instead of the points -- and it did, landing the pair symmetric about x = -8.18. It now measures signed perpendicular distance to the axis where the axis actually is, which is the stronger property anyway. Coverage: 20/20 buttons pressed, up from 9. Ladder 135 -> 177 properties across 43 rungs, all holding. snaporca-l2vm |
||
|
Tommaso Bianchi
|
8f3f835636 |
Constrain while you sketch, and stop losing work to Esc and to invisible points
Five defects from ten minutes of real use, and the mode split behind the worst of them. One commit because the changes overlap in the same functions; the pieces are separable in the diff, not in the file. CONSTRAINING NO LONGER NEEDS A COMMITTED SKETCH. A constraint could only be applied by committing the sketch, selecting it in the feature tree, pressing the padlock, and only then picking. While drawing, the CONSTRAIN toolbar was not even on screen (set_ui_mode showed it in UiMode::Constrain alone) and apply_constraint answered "Press Constrain on a sketch first" -- in a status line nobody looks at. Draw two lines, press Parallel, get nothing: that is what a user reported as "the UX is a mess", and they were right. apply_constraint now takes the live session first, reading the picks from the selection model the sketch tool already had (click, ctrl-click to extend, double-click for the loop) and applying through try_add_constraints, which already did append -> solve -> keep-or-rollback. The committed Constrain path stays for editing an old sketch; it is no longer the only way in. The twenty constraint buttons now show in Sketch mode as well. The discriminator is is_sketching() && !is_constraining() && !is_constraining_entities(). Both begin_constrain and begin_constrain_entities set m_active, so is_sketching() alone is true DURING a constrain session and the new path would hijack the old one -- compiling perfectly and failing in behaviour. ONE PLANNER, NOT TWO. A second caller meant duplicating the logic that decides whether a constraint is legal, which roles it binds and whether it needs a typed value. That duplication is how today's Coincident bug survived: fixed in one branch, alive in the next one down. plan_entity_constraint() now lives in the kernel -- pure, no wx, no translation -- and both UI paths call it. DesignPanel loses 304 lines and gains 155. Being in the kernel makes it TESTABLE. The Parallel defect existed because a constraint type met an entity type nobody had tried, and the only instrument was a 13-minute GUI ladder. 19 new kernel cases cover the matrix: 264 -> 283 cases, 7648 -> 7867 assertions. Parallel, Perpendicular and EqualLength gain the two-line guard they never had. On non-lines they used to emit a def the solver silently dropped -- the sketch reported itself constrained when it was not, the same class as Horizontal on a Point. EqualLength on two rounds still promotes to EqualRadius first. Symmetric is planned completely, including its axis pick: the plan carries a VECTOR of defs because Symmetric on two lines is two constraints (P0/P0 and P1/P1). A single def would have half-applied it -- one end pinned, one free, looking correct until something moves. A PLACED POINT SURVIVES THE COMMIT. Type::Point was created correctly and never drawn once committed: both renderers skip it, correctly, since entity_polyline gives a point nothing. What was missing is the vertex-marker path the live session already used. rung_point passed throughout because it asserts the document, and the point was always in the document -- the pixels lied. ESC STOPS EATING AN UNSAVED SKETCH. The third press reached cancel_sketch(), clearing m_entities with no warning and nothing to undo. live_sketch_has_work() existed and was never consulted. The exit layer refuses once when there is work and lets a second consecutive Esc through; the refusal re-arms on a button press, never on mouse motion, or Esc could never exit while the hand moves. TWO NEW RUNGS. D10 drives Parallel through the committed path -- it passes on the PRE-fix binary, which is how we know the user's failure was the mode and not the constraint. D11 is the acceptance for the collapse: draw, pick both, press Parallel, no commit and no padlock. Ladder 126 -> 135 properties, all holding. CON_BTN_SKETCH is measured, not derived: in Sketch mode the group renders after the sketch toolbar, so the first button is at 677, not 449. Pitch 42, twenty buttons, read off a screenshot. Deriving it by offset is how that table drifted the last time. Known limit, commented at the call site: a constraint added to a LIVE sketch is not on the document undo stack, so Ctrl+Z will not take it back until the sketch is committed. snaporca-itp4, snaporca-oyhx, snaporca-l2vm |
||
|
Tommaso BianchiandClaude Opus 5
|
cd30fb891e |
the same phantom-endpoint bug in Coincident, and the two unguarded branches next to it
Port of snaporca da8d011b87; parity holds (DesignPanel.cpp still exactly 32 divergent
lines). Verified independently on this fork's own rig: full ladder 126/126 against
BuildID 96c697a3, built from this tree.
Reviewing the DistanceX/Y fix for OTHER members of its class found three more live defects
on the constrain toolbar. All four share one root: a branch assumes every picked entity has
two endpoints, and the solver's refusal to resolve a role it cannot find is silent.
COINCIDENT had the identical closest-pair walk over {P0,p0},{P1,p1}. For two Points the
phantom (0,0) pair sits at distance 0, which is the smallest distance there is, so it
ALWAYS won: ptOf(Point,P1) -> 0, ref_ok fails (SketchSolver.cpp:185), constraint dropped.
Not sometimes -- every press.
HORIZONTAL/VERTICAL hardcoded ra=P0, rb=P1 with no type check. With a Point picked the
constraint is dropped by the same mechanism but still STORED: constraints goes 0 -> 1 after
the commit and nothing moves, so the Constraints list shows a dimension that can never do
anything. Worse than refusing -- the panel claims the sketch is constrained when it is not.
ANGLE computed p1-p0 on whatever was picked. On a circle that is (0,0)-centre, so two
circles pre-filled the field with the angle between their centre POSITION VECTORS (178.83
deg for two on the x axis), and accepting it emits SLVS_C_ANGLE on two circle prims.
Both branches now refuse with a message. entity_ends()/closest_ends() are file-scope and
shared by Coincident and DistanceX/Y, so there is one implementation instead of two that
drift.
Two smaller findings from the same review: infer_auto_constraints' roles_of omitted
EllipseArc while heal_coincidences' identical copy has it; and set_point(Circle, Center)
wrote e.center and not e.p0, breaking the "p0 mirrors centre" invariant for the duration of
a live drag.
New rungs D8 and D9, both RED against the shipped binary and green here.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MrMzTpAf78U4NG2M8jfvHY
|
||
|
Tommaso BianchiandClaude Opus 5
|
afb17e8889 |
D3 was testing luck: the pair started 3 degrees from square, inside inference's snap
Port of snaporca b3221f8a12; this is the fork the fault surfaced on. The perpendicular rung drew its two lines 93.5 degrees apart and then asserted they did NOT start perpendicular. On this rig, whose camera maps the same click a pixel differently, they arrived at exactly 90.000000 -- inference had already done the job the rung exists to test, so the precondition failed while every later check passed. Held on the other fork and failed here from identical source: the rung depended on where a click happened to land, not on the app. The second point now starts the pair 56 degrees off, well outside any snap tolerance, so the button has real work to do. That immediately exposed a second, milder fault in the same rung. From a 51 degree start the LIVE solve converges to its own tolerance and lands at 89.999999991; the old 1e-9 assertion held only because the correction used to be tiny -- it was measuring how little work the solver had to do, not whether the lines came out perpendicular. It is 1e-6 degrees now, which is 1.7e-8 radians. The round-trip check still demands exactly 90 and gets it, because the committed feature re-solves from scratch. Full ladder 118/118 on BOTH rigs after this, each driving its own fork's binary. This fork had never had a green gesture ladder before today (snaporca-eoj1). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MrMzTpAf78U4NG2M8jfvHY |
||
|
Tommaso BianchiandClaude Opus 5
|
d35d33971a |
the feature-tree row needs CHROME_DY too — the last chrome constant that did not carry it
Four of this fork's five absolute chrome coordinates were shifted by CHROME_DY when the
ladder was first brought up here (DESIGN_TAB, CONSTRUCTION_CHECKBOX, CON_BTN_Y,
CONFIRM_BTN). TREE_ROW0 was not, because it is declared above the CHROME_DY block and was
simply never in view.
The unshifted click lands 26 px below the first tree row, just past its 23 px height, so
the row is never selected and Delete does nothing. reset_document then spends 40 rounds on
it and dies with "could not empty the feature tree" — a message that names the feature
tree, which is not the fault. The same 26 px is why confirm_and_reopen's double-click did
not reopen the sketch, which surfaced as "sketch_describe: no sketch is open" three frames
away from the cause.
Measured, not inferred: the Sketch1 row centre reads y=241 on the rig at 1920x1080 with
the window at (0,0), against the constant's 215. CONFIRM_BTN was checked in the same pass
from a screenshot taken in CONSTRAIN mode and is correct at (1751, 101).
With this, the four new constraint rungs hold 20/20 on this fork's rig, driving the binary
built from
|
||
|
Tommaso BianchiandClaude Opus 5
|
648b930e75 |
gesture rungs for the six new constraint buttons, and the DistanceX/Y bug they found
Port of snaporca 2951e3c60b; parity holds (17 identical, DesignPanel.cpp still exactly 32
divergent lines, so the hunk landed on the right side of the DropDown divergence).
The sketch-constraint epic added six toolbar buttons and covered all six with kernel
tests. Not one of them was ever clicked. The gesture ladder only pressed 'perpendicular'
and 'equal' -- and CON_BTN, which locates buttons by index, was silently wrong for every
entry past index 5 for the whole epic. The untested half of the toolbar was exactly the
broken half (snaporca-rqsy).
Four rungs now drive them: D4 Equal on two circles (must mean equal RADIUS, not the
equal-length no-op the epic fixed), D5 Collinear on two oblique lines, D6 a horizontal
distance, D7 symmetric about the implicit vertical axis. Full ladder 118/118 on snaporca;
this fork's rig has not been rebuilt against the change yet, so here it is reviewed,
parity-checked and NOT exercised.
D6 found a shipped defect. apply_entity_constraint enumerated {P0,p0},{P1,p1} for BOTH
entities regardless of type, but a Point's p1 is unused and reads (0,0), as does a
Circle's. The closest-pair search then picked those two phantom origins, distance 0: the
field opened pre-filled 0.00 and the solver dropped the constraint, because ptOf(Point,P1)
resolves to no handle. Nothing errored -- the dimension simply did nothing. ends_of() now
enumerates only the roles an entity actually exposes, and the pair with no point at all is
refused with a message instead of a silent no-op.
Five kernel tests, a 7/7 ladder, a review and a fork port all passed over this, because
every one of them exercises the kernel, where the geometry was always right.
Two rig faults fixed in the same pass, both of which produce a green-looking session that
tests nothing: start-headless-gui.sh never exported SNAPORCA_MCP or SNAPORCA_KEYTRACE, so
a freshly launched rig comes up healthy and every ladder dies on "Connection refused"; and
it never dismissed the "Restore" dialog a killed session leaves behind, which grabs every
synthetic click afterwards.
The value field also takes no keyboard focus from the WM -- typed digits go to the canvas
and Return commits the pre-filled number (typed 40, got 54.94). focus_field() finds it as
its own top-level window and clicks it first. The no-op tolerance is now 5e-3, the field's
own two-decimal display resolution, not 1e-6.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MrMzTpAf78U4NG2M8jfvHY
|
||
|
Tommaso Bianchi
|
d0791c3b8a |
Make the ladder runnable on this fork's rig — 6 of 7 rungs now hold
This fork had never been gated end to end. Five separate things stopped it, none
of them a defect in the CAD code itself, and each failure named the wrong
subsystem — which is why they survived.
1. run-all-checks.sh invoked docs/ux/mockups/gen_offer_table.py. The design docs
moved to docs/CAD/ (
|
||
|
Tommaso Bianchi
|
ca8f813994 |
Add assimp to the deps image, so this fork can run its own tests
This fork's kernel suite has never run. scripts/CAD/run-kernel-tests.sh died at CMake CONFIGURE time on find_package(assimp REQUIRED), before a single source file compiled, so every kernel change ported here was parity-checked against snaporca and never independently tested (snaporca-w80c). WHY IT WAS MISSING. OrcaSlicer mainline gained assimp (glTF/GLB/FBX import for texture-to-colour) after the orcacad-deps image was baked: the image's deps/ tree has no Assimp directory at all and nothing named assimp anywhere in it. On the host, deps/build/dep_Assimp-prefix carries only `patch` and `update` stamps -- no build, no install -- so the dependency was fetched and then never built, inside the image or out of it. The Snapmaker fork never hit this because its base requires neither assimp nor OpenCV. WHY A LAYER. A full deps rebuild is hours and would rewrite artifacts that currently work; this adds the one missing package on top. It is a Dockerfile rather than a `docker commit` so that what was done stays reviewable and repeatable instead of being an undocumented image mutation. The flags are the project's own recipe (deps/Assimp/Assimp.cmake) plus the standard superbuild arguments from orcaslicer_add_cmake_project (deps/CMakeLists.txt:158) and DEP_CMAKE_OPTS (deps/deps-linux.cmake). The file says to keep them in step with that recipe: it stands in for the superbuild, it is not a separate opinion about how to build assimp. The tarball's SHA256 was checked against the recipe's URL_HASH before this was written and is re-checked inside the build, and the build asserts the installed cmake config exists rather than trusting an exit code. OpenCV was confirmed already present, so it is not a second wall behind this one. RESULT, and it is the point: orca_cad kernel now runs and is GREEN at 7701 assertions / 270 cases. snaporca is 7700 / 270 -- same cases, one more assertion here, which is the tolerated test_caddocument.cpp divergence. The "this fork's kernel suite cannot run" caveat carried by the five commits of the sketch constraint epic no longer applies. |
||
|
Tommaso Bianchi
|
b5ead4b29f |
Pull a body's edges into a sketch as construction references
Port of snaporca e635627b81. Parity OK: 17 files identical, 8 diverging at their expected counts. The last reference an industrial sketcher offers that this one did not: Onshape's Use, SolidWorks' Convert Entities. Project already turned a body's 3D edges into 2D Lines, Circles and Arcs on a plane, but the result landed in its OWN feature, so while drawing in one sketch you could not borrow an existing body's edge and constrain to it. No new geometry code: Project's per-edge conversion loop is factored into project_edges_to_entities() and called from a second entry point that appends into an EXISTING sketch with construction = true. The loop appears once now, not twice. Construction is what makes it cheap and safe: SketchEngine already skips construction entities when building wires, so the references guide without being built, and being otherwise ordinary entities every constraint from this epic -- Collinear, EqualRadius, the axis-projected distances, PointOnLine, Symmetric -- works against them for free. Part of this refactors working code, so Project's behaviour identity is the invariant; the existing [CadDocument][project] cases guard it and a new case asserts a Project feature still emits construction == false. project_edges_into_sketch returns the number of entities appended, or -1 on a bad reference rather than throwing. VERIFICATION LIMIT, as with the previous four commits: this fork's kernel suite still cannot run (find_package(assimp) at configure time, snaporca-w80c). Shared sources are byte-identical to snaporca's, where kernel is 7700 assertions / 270 cases and ALL LADDERS HELD 7/7. |
||
|
Tommaso Bianchi
|
fac3cf44df |
Infer parallel, perpendicular, equal radius and tangent while drawing
Port of snaporca 2d36d28770. Parity OK: 17 files identical, 8 diverging at their expected counts. infer_axis_constraint returned only Horizontal or Vertical. On the CAD-1000-hours corpus the top two transitions are sketch_dim -> sketch_draw (5896) and back (5756): the signature of geometry that does not self-constrain as it is drawn. Every rule requires the relation to be ALREADY TRUE within tolerance, so nothing the user drew is moved; parallel/perpendicular and tangent additionally require a shared endpoint. TWO LIMITS THE CORPUS RUNG FORCED, neither visible to the unit tests: 1. At most ONE constraint per rule per new entity, not one per PAIR, and no one-at-a-time fallback for the relations batch. EqualRadius has no locality restriction, so 200 equal holes produced ~20000 candidates; the rejected batch then cost a solve per constraint and pinned the app at 95% of a core with the MCP socket unresponsive. 2. Relations only for gesture-sized batches. "A scripted add is not a drawn gesture" is already this file's rule at its bulk call site (snaporca-8xg1), and EqualRadius also couples geometrically distant entities, merging independent connected components and defeating the partitioning that makes large sketches solvable (snaporca-yww4). With the cap alone geometry stayed correct (32/32 sheets clean) but seven of the largest timed out, including MPD681 -- the sheet that call site's own comment names. Also fixes the tolerance leak behind 2: the bulk path asks for exact inference with ang_tol_rad = 0 but len_tol_frac kept its 0.01 default. ALSO independent of this feature: run-kernel-tests.sh defaulted to TAGS=[CadDocument] while four CAD test files carry their own tags and nothing selected them (2624 assertions / 206 cases reported, 7648 / 264 actual). All 58 dark cases were passing; the coverage was never exercised. VERIFICATION LIMIT, as with the previous three commits: this fork's kernel suite still cannot run (find_package(assimp) at configure time, snaporca-w80c). Shared sources are byte-identical to snaporca's, where kernel is 7651 assertions / 265 cases and ALL LADDERS HELD 7/7. |
||
|
Tommaso Bianchi
|
45494c6035 |
The origin and the two axes become things you can constrain to
Port of snaporca 5b1294de59. Parity OK: 17 files identical, 8 diverging at their expected counts. Every industrial sketcher gives you the origin and the axes as references. Here the origin was only a SNAP target and the axes did not exist, so Symmetric needed a third picked ENTITY as its mirror axis: symmetry about the sketch's vertical axis first required drawing a construction line. Every constraint reference resolves through four lambdas in the solver (valid/ptOf/primOf/coordOf), so teaching those about three negative sentinel indices makes the origin and both axes available to EVERY constraint type at once. No new SketchEntity type, no serialization change; -1 still means "unset". The references live in G_FIXED and add no degrees of freedom, which a test asserts via the reported DoF. SymmetricAboutY / SymmetricAboutX are two buttons that need no third pick and no construction line. Making the axes clickable in the viewport is deliberately left out: that is canvas hit-testing work with its own risks. Recorded in the tests because it will catch the next person: sys.dragged[] is populated only during a drag, so a plain sketch_solve of an UNDER-constrained system may move any free parameter -- solvespace runs Newton, it does not minimise movement. PointOnLine onto an axis is one equation in two unknowns and the point legitimately slides along it. Those tests pin the free direction instead of asserting the other coordinate is untouched. VERIFICATION LIMIT, as with the previous two commits: this fork's kernel suite still cannot run (find_package(assimp) fails at configure, snaporca-w80c). The shared sources are byte-identical to snaporca's, where kernel is 2624 assertions / 206 cases and ALL LADDERS HELD across all seven rungs. |
||
|
Tommaso Bianchi
|
a63bba2d55 |
Horizontal and vertical distance dimensions
Port of snaporca 9fa304c77a. Parity OK: 17 files identical, 8 diverging at their expected counts. The everyday dimension in SolidWorks and Onshape, and this kernel had no form of it. Distance constrains the straight-line gap; LockX/LockY pin one point's ABSOLUTE coordinate. Neither relates two points along an axis. DistanceX/DistanceY emit SLVS_C_PROJ_PT_DISTANCE against two unit direction lines built in the solver's G_FIXED group, so they add no degrees of freedom. THE DIRECTION IS SIGNED, and getting it backwards is silent. libslvs defines a LINE_SEGMENT's direction as point[0] - point[1] (entity.cpp) and PROJ_PT_DISTANCE constrains (pB - pA).dot(dir) (constrainteq.cpp:234), so the reference lines are built head-first to mean +X and +Y. The same signedness was a real defect in the GUI: the inline editor was pre-filled with |delta|, so when the closest endpoint pair ran right-to-left, opening the dimension and accepting the number shown would flip the point to the other side of its anchor. Opening a dimension and accepting its own value must be a no-op. The refs are now ordered so the shown value is positive. On the CAD-1000-hours corpus, dimensioning and constraining is 31.9% of all observed CAD time -- the largest single class, 7.6x feature operations. This is the item in the constraint epic that lands most directly on it. VERIFICATION LIMIT, as with the previous commit: this fork's kernel suite still cannot run (find_package(assimp) fails at configure time, snaporca-w80c). The shared sources are byte-identical to snaporca's, where kernel is 2603 assertions / 200 cases and ALL LADDERS HELD across all seven rungs. |
||
|
Tommaso Bianchi
|
a1f2a2687a |
Equal radius and Collinear, and one Equal button that knows what it picked
Port of snaporca 9ec6405e2d. Parity OK: 17 files identical, 8 diverging at their
expected counts (DesignPanel.cpp 32, test_slvs_constraints.cpp 3).
Measured on the CAD-1000-hours corpus: 51.5% of observed CAD time is 2D sketch
work, and dimensioning/constraining alone is 31.9% -- the largest single class.
Two constraints every industrial sketcher has were missing here.
EqualRadius fixes a dead end rather than adding a feature. Picking two circles
and pressing Equal emitted EqualLength, which maps to SLVS_C_EQUAL_LENGTH_LINES
and constrains nothing on a curve: a silent no-op with no error. Equal is now
one button with two meanings, as in Onshape and SolidWorks.
Collinear emits PARALLEL plus PT_LINE_DISTANCE=0 rather than PT_ON_LINE, whose
internal valP param this libslvs port leaves at 0, drifting an already-collinear
pair.
Both types are appended at the END of SketchConstraintType: cereal serializes it
positionally, so inserting elsewhere reinterprets every saved recipe.
VERIFICATION LIMIT, stated rather than implied: this fork's kernel suite could
NOT be run. scripts/CAD/run-kernel-tests.sh fails at CMake configure time on
find_package(assimp), before any source compiles -- a pre-existing deps gap
(snaporca-w80c), not this change. The shared sources are byte-identical to
snaporca's, where the full gate passed: kernel 2588/195 and ALL LADDERS HELD
across all seven rungs.
Also fixes two defects in this fork's scripts/CAD/run-all-checks.sh:
- `cd $(dirname $0)/..` landed in scripts/ instead of the repo root, so every
rung looked for itself under scripts/scripts/. Broken since the script moved
into scripts/CAD/; the three sibling scripts were fixed then and this was
missed, so the gate has not run since.
- C defaulted to snaporca-gui, the OTHER fork's rig container, so this fork's
gate would drive snaporca's app and report green about the wrong binary.
run-kernel-tests.sh:31 documents the identical defect being fixed once
already for the build volume; this is the third instance.
|
||
|
Tommaso Bianchi
|
884a382a48 |
Esc leaves the sketch from the state you are actually left in
exussum12 on PR #15238: "Esc hardly ever works". He was right, and the word that matters is "hardly" — it works while you are mid-entity and stops working the moment you finish one. The branch asked whether a DRAW TOOL was armed, not whether a SKETCH SESSION was open: if (key == WXK_ESCAPE && m_viewport && m_viewport->is_sketching()) is_sketching() is DesignSketchTool::is_active(), true only between arming a tool and finishing with it. Commit an entity and you are left at ui_mode=Sketch with no tool armed, and from there Esc did nothing at all, no matter how many times you pressed it — the Cancel button was the only way out. Reproduced on the headless rig with SNAPORCA_KEYTRACE, which is what settled it rather than reading: the key ARRIVES and focus is fine, [KEYTRACE] key=27 ui_mode=1 is_sketching=0 in_text=0 inline_busy=0 focus=w so this was never the focus problem it looks like from the outside. Gate on the session instead. request_exit() is already layered — abort the in-progress entity, else drop the tool to Select, else exit to Feature — so widening the gate adds no new behaviour, it just lets the ladder be reached from its own last rung. is_sketching() stays in the condition as an OR, so nothing about the armed-tool path changes. This is the same mistake snaporca-0ud fixed thirty lines above in the same handler, where gating the sketch key MAP on is_sketching() made all 17 keys read as dead. The comment there now has a sibling. VERIFIED ON THE RIG, before and after, same sequence (Design > XY > Shift+S > click canvas): before, two Escapes left the toolbar on SKETCH with zero pixels changed; after, the toolbar reads FEATURES — one Esc drops the armed tool to Select, the second exits the session. Kernel suite green, 2568 assertions in 191 test cases. libslic3r_gui builds clean on both forks. Parity 17 identical / 8 diverging as expected. |
||
|
Tommaso Bianchi
|
13d5eac891 |
Move the Design-tab scripts into scripts/CAD/ and name them by role
Requested by SoftFever on PR #15238: ten of these had accumulated loose in scripts/ next to ~20 unrelated upstream ones, with names that only meant something to whoever wrote them. They now sit in scripts/CAD/, mirroring the src/libslic3r/CAD/ and src/slic3r/GUI/CAD/ split, and the verb in the name is the role: build- produces a binary, start- brings something up, run- runs a suite, check- asserts one thing against a live app. kernel-test.sh -> CAD/run-kernel-tests.sh ladder-all.sh -> CAD/run-all-checks.sh sketch-ladder.py -> CAD/check-sketch-engine.py ladder-corpus.py -> CAD/check-sketch-engine-corpus.py gui-ladder.py -> CAD/check-gui-sketching.py offer-ladder.py -> CAD/check-gui-context-menu.py mcp-sketch-smoke.py -> CAD/check-mcp-sketch.py rig-build.sh -> CAD/build-gui.sh docker-iter-build.sh -> CAD/build-gui-incremental.sh gui-session.sh -> CAD/start-headless-gui.sh "Ladder" was the worst of them: it named the shape of the test (rungs of increasing difficulty) rather than what the test proves, so nothing in the directory listing told you which one needed a GPU and which was pure kernel. Every reference rewritten -- the docs, the cross-calls between the scripts, Dockerfile.deps, and the container-side /OrcaSlicer/scripts paths. The three shell scripts resolve REPO relative to themselves and now sit one level deeper, so that walk went from /.. to /../.. . The copies these push into a container's /tmp were renamed to match, or the container would have kept the old names alive. Two runtime paths deliberately NOT renamed. /tmp/orca-rig-build.lock is a cross-fork contract -- both forks take the same lock so two concurrent builds serialise instead of OOMing the box, and renaming it on one side silently removes that guard. /tmp/gui-session.log is a runtime artefact, not a script. Added scripts/CAD/README.md: what each script proves, what it needs, and the two constraints that have each cost a session (never build inside the GUI container; a window manager is required or synthetic keys are ignored). On CI, which was the other half of the request: the kernel suite is already there and always has been. The cases are registered in tests/libslic3r/CMakeLists.txt under if (SLIC3R_CAD), which defaults ON and no workflow turns off, so they build into libslic3r_tests and run under ctest on every platform via unit_tests.yml -- like any other unit test, needing no new job. They have simply never been seen to run, because the workflows on this PR are still awaiting maintainer approval. run-kernel-tests.sh is the local loop over the same cases, and it is the only script here CI could run: the other six need an OpenGL canvas and synthetic input. Verified: scripts/CAD/run-kernel-tests.sh from its new location, all tests passed, 2562 assertions in 190 test cases. |
||
|
Tommaso Bianchi
|
cdd41e230d |
The Design tab's MCP socket must not wait for someone to click the tab
Building the Design tab on first use (
|
||
|
Tommaso BianchiandClaude Opus 5
|
3fd5c3353a |
A reference is a reference whatever feature holds it
Port of snaporca 1bb9825db0. Four defects from an independent 20-agent audit, each verified in the code first; two further findings from the same report were verified OUT and are not in this commit. remove_feature()/move_feature() remapped Extrude::sketch_ref and a Mate's two connectors and nothing else, leaving seven of the nine index-bearing fields — sweep_path_ref, loft_profile_refs[], pattern_curve_sketch, rib_sketch_ref, and sketch_ref on Revolve, Sweep, Rib and the Surface* family — pointing at whatever slid into the slot. Quiet by construction: the shifted index still names a real feature, recompute() succeeds, the solid is built from the wrong profile. The comment above the loop already required "EVERY field holding a feature index"; the code under it handled two, because a type switch is only correct on the day it is written. for_each_feature_ref() visits the FIELDS instead, so a feature type added later is covered the moment it reuses one. plane_base and axis_plane_a/b are excluded on purpose and documented at the helper — they encode an ordinal into the datum-plane list, not an index into features[], and are filed separately. The delete cascade got the same field-based treatment. The regression test was run against the pre-fix code to prove it bites: all three sections fail there, and move_feature returns TRUE while leaving sketch_ref == 1 where it must be 0 — success with the wrong answer, which is what makes this class expensive. apply_constraint, commit_entity_constraints and delete_constraint mutated the recipe with no checkpoint() and no sync_recipe_to_model(), alone among seventeen mutation sites in that file: Ctrl+Z reached past the constraint edit and discarded unrelated work, and saving persisted the pre-constraint blob. A rejected constraint now calls abandon_checkpoint() rather than leaving an undo step that does nothing. MCP: params["generation"].get<uint64_t>() sat outside the try inside a bare CallAfter lambda, so one malformed string terminated the process through the wx event loop; it is type-checked now and the lambda lets nothing escape. The socket bound with no mode of its own in a world-writable directory — umask around bind() plus chmod, and it refuses to listen rather than listen wide. The reply write is no longer a bare write(), which could SIGPIPE the app when a client hung up. Kernel suite on this fork: 190 cases / 2562 assertions, green. GUI target compiles. The full ladder gate ran on snaporca (ALL LADDERS HELD — gestures 98/98, offer 108/108, corpus and corpus-scale green) and fork-check parity holds at 17 identical / 8 diverging as expected, which is what makes that gate transferable here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MrMzTpAf78U4NG2M8jfvHY |
||
|
Tommaso Bianchi
|
6e7f6429fa |
A body carries its own name, because a body is not its first feature
User report 2026-08-23, and it is right: "you have renamed the feature extrusion,
not the body. i clicked rename on the body feature tree and the feature extrude
changed name. this means that you consider the extrusion = the body. this is very
far from truth as a body can contain several extrusions."
That is exactly what the previous commit did. It resolved a selected body to
CadBody::source_feature and renamed THAT feature, on the reasoning that a body has
no name of its own. The reasoning described an implementation detail — CadBody::
name is derived and restamped on every recompute — and mistook it for the user's
model. An Extrude, a Cut and a Fillet all land on the same body: the maker is one
operation in its history, and renaming it renames the wrong object.
A body now has a name of its own. CadBody::user_name, set only by a rename, is:
- carried across recompute() by body index, next to the per-body colour override
and under the same index contract the GUI already relies on for visibility and
Move — without which a name would survive exactly until the next feature;
- written into the recipe, because bodies are recomputed and never serialised, so
a name has nowhere else to live and would otherwise vanish on reopen;
- shown on the Bodies row ahead of the derived maker name, as "Body N — name",
with the number still leading because every status line, the interference
report and the mate errors identify a body that way.
The recipe block is APPENDED after the variables block rather than given a version
bump. A build that predates it reads features and variables, returns, and never
looks at the trailing bytes — so yesterday's projects open here and today's
projects still open there. A bump would have cost every project written today its
readability by the previous build, for one optional field.
Renaming a FEATURE is unchanged. The feature tree renames features; the Bodies
list renames bodies; neither reaches into the other.
WHAT THIS COST, and why it is written down. Getting here took two wrong turns
inside one fix, both mine:
1. UnselectAll() -> Unselect(). Both trees are wxTR_SINGLE, where UnselectAll()
— the MULTI-selection call — does nothing. That was the one-word reason the
rename had been vetoed everywhere (BEGIN_LABEL_EDIT refuses while
tree_body_selection() >= 0). Fixing it turned a pair of harmless no-ops into
a real loop: the two lists clear each other so "the target" is unambiguous,
so clicking a body row ran apply_body_row -> m_tree->Unselect() -> the feature
tree's SEL_CHANGED -> m_parts->Unselect(), which cleared the row just clicked.
The handler now clears the other list only when it actually holds a selection.
2. Trusting a screenshot taken after a polluted run. A leftover Rib card had
shifted the whole panel, so a click measured against it landed nowhere near
the row. Relaunch, then measure.
VERIFIED, on the rig and in the kernel:
body renamed ('Extrude', user_name=False) -> ('Bracket', user_name=True)
features untouched ['Sketch', 'Extrude'] before and after
survives a recompute add a Hole to the same body: features become
['Sketch', 'Extrude', 'Hole'], body stays 'Bracket'
survives the recipe serialize -> deserialize -> 'Bracket'
New kernel test "a body carries its own name, through recompute and the recipe"
pins all three properties; the suite is 189 cases / 2547 assertions.
Gate green: ALL LADDERS HELD — offer table matches the atlas, kernel suite,
engine rungs 1-8, 977-sheet corpus + the heaviest sheets, gesture ladder 98/98,
offer ladder 108/108.
|
||
|
Tommaso Bianchi
|
0ac9ac91f7 |
A body can be renamed, and the one-word reason it could not
User report 2026-08-23: "clicking on a body row in feature tree, I cannot find
rename on right click", then "still i cannot rename body1 in custom name".
TWO SEPARATE CAUSES, one in data and one in a single method call.
THE MISSING ROW WAS DATA. The `rename` verb's accepts list in the tool atlas was
["sk_loop"] alone, so the offer built for a selected BODY carried no Rename row.
Right-clicking a body row already opens the offer — that is the designed gesture,
bound on m_parts as wxEVT_TREE_ITEM_MENU — so the menu the user was looking at
was the right menu, and it was simply missing the verb. accepts is now
["sk_loop", "body_solid"], the generated table regenerated with it (the accept
mask moves 0x00004000 -> 0x00004080), and the offer trace confirms the row:
"[OFFER] row=7 Modify > rename".
THE RENAME ITSELF WAS BLOCKED BY UnselectAll(). Both trees are wxTR_SINGLE, and
wxTreeCtrl::UnselectAll() is the MULTI-selection call: on a single-selection tree
it leaves the row selected. So every path that tried to open the label editor
while a body row was selected hit the BEGIN_LABEL_EDIT guard — which vetoes while
tree_body_selection() >= 0, the rule that stops a body taking a name it cannot
keep across a recompute — and the editor never opened. Unselect() is the call
that works, and it fixes every route at once.
That took five attempts, four of them wrong, and the reason they were wrong is
worth more than the fix: each one addressed a plausible cause that the evidence
did not actually support — the popup's nested event loop, keyboard focus,
deferring with CallAfter, dispatching through a different verb. What settled it
was a DISCRIMINATOR rather than another fix: pressing F2 on a selected body row
takes the same handler with no menu and no nested loop. F2 failed identically,
which ruled out every menu-shaped theory in one measurement and left only the
state the veto reads.
A body still has no name of its own — it is recomputed from the recipe on every
change and CadBody::name is derived from the feature that builds it — so the verb
resolves the body to CadBody::source_feature and renames THAT, saying so on the
status line: "A body takes its name from the feature that makes it — renaming
'Extrude'". The Bodies row now reads "Body 1 — Extrude" so the rename is visible
where it was made; the positional "Body N" leads, because every status message,
the interference report and the mate errors identify bodies that way. Confirmed
as the wanted format by the user.
Also here, from the same report: the Bodies card keeps its own action row (Move,
Show / hide, Delete, Colour), and the competing context menu an earlier pass had
added to body rows is REMOVED — right-clicking a body belongs to the offer, and
two menus on one gesture is how the offer ended up being blamed for a veto.
Verified on the rig, both routes, with a body selected:
F2 on the body row -> ['Sketch', 'Extrude'] became ['Sketch', 'Base block']
the offer's rename verb -> {'applies': True, 'dispatched': True,
'selection_kind': 7, 'ok': True} and the same rename
Gate green: ALL LADDERS HELD — offer table matches the atlas, kernel 188 cases /
2532 assertions, engine rungs 1-8, 977-sheet corpus + the heaviest sheets,
gesture ladder 98/98, offer ladder 108/108.
RIG DISCIPLINE, repeated twice in one session and now written down: ladder-all.sh
does not relaunch the app, so hand-driving the rig immediately before a gate
leaves state its reset_document() cannot clear — both times the first rung drew
nothing and reported "sides []", which reads exactly like a broken rectangle
tool. Relaunch before gating.
|
||
|
Tommaso Bianchi
|
b0657fb2c9 |
The row menu carries the whole row, and Move body goes where bodies live
Two decisions from the user, 2026-08-23, after the first pass at making rename reachable. ONE SURFACE CARRIES THE VOCABULARY, and it is the row's own menu: Rename (F2), Edit, then Move up, Move down, Show / hide, then Delete. Offered as a choice between completing the menu or completing the header icons; the menu won because the element you click answering with what applies to it is this fork's charter, and because a menu grows without spending an icon nobody recognises. The header icons stay exactly as they are — a quick bar for the common three — so nothing that worked yesterday moved. The menu is grouped rather than listed: what the row IS (name, contents), where it SITS (order, visibility), and what removes it. Right-click SELECTS what it points at before opening, so the menu can never act on a row other than the one under the cursor. MOVE BODY LEAVES THE FEATURE-TREE HEADER. It never belonged there: that header sits over the FEATURE tree, and the button had to guess its subject from whatever happened to be selected — a feature row got answered with "Select a body to move it", an instruction about a different kind of object in a list that does not contain one. A body now has its own action row on the Bodies card: Move, Show / hide, Delete, Colour. The last three are deliberate COPIES of feature-tree actions, not a reorganisation: a body row is a different subject, and someone working in the Bodies list should not travel to another card to hide or recolour what they have just selected. Each handler already resolves the body row itself (on_toggle_visibility, on_delete_body, on_set_body_color), so the card gives them a home and decides nothing. The offer already carried Move for a selected body (verb `transform`, accepts body_solid), so that half of the requirement was in place and is untouched. One piece of the old button was function, not clutter: it also scaled imported Text/SVG artwork, which IS a feature-row action. That moved to the row's own menu as "Scale artwork", shown only on a row that has imported regions — so the capability survives the split instead of disappearing with the button. Verified on the rig, by the gestures themselves: right-click a row -> the six items in their three groups; choosing Move down turned ['Sketch1', 'Sketch2'] into ['Sketch2', 'Sketch1']; and with a body present the Bodies card shows its four actions while the feature header no longer shows Move. Gate green: ALL LADDERS HELD — offer table OK, kernel 188 cases / 2532 assertions, engine rungs 1-8, 977-sheet corpus + the heaviest sheets, gesture ladder 98/98, offer ladder 108/108. RIG DISCIPLINE, learned the expensive way in this session: ladder-all.sh does NOT relaunch the app, so hand-driving the rig immediately before it leaves state the ladder's reset_document() does not clear — here the first rung drew nothing at all and reported "sides []", which reads exactly like a regression in the rectangle tool. Relaunch the app before a gate, and re-run before believing a failure that appears in rung one. |
||
|
Tommaso Bianchi
|
3d3324d663 |
A feature-tree row can be renamed by someone who does not already know F2
User report 2026-08-23: "on feature tree, i cannot rename sketch name". The rename was not broken. Verified on the rig before changing anything: select the row, press F2, type, Enter — Sketch1 becomes Base, the name reaches m_doc.features[idx].name and sync_recipe_to_model() persists it. The offer's btn:rename verb does the same. What was missing was any way to find that out. Everything a person would try did something else: - the pencil in the section header is EDIT (on_edit_feature) - a double-click fires wxEVT_TREE_ITEM_ACTIVATED, which is also Edit - none of the seven header icons renames - right-clicking a row did nothing at all and the comment above the label-edit handlers claimed a "slow double-click" renames, which does not survive wxGTK: the activation wins and the sketch opens for editing instead. So the only route was an undocumented function key, and the report is exactly right from where the user stands. The row now answers the gesture people actually use on a named row: right-click gives Rename (F2) / Edit / Delete, with Rename opening the in-place editor on that row. Right-click SELECTS what it points at first, so the menu can never act on a different row than the one under the cursor. And selecting a row now says what the row can do: "Sketch1 selected — F2 or right-click renames it, double-click edits it". Cheaper than a tooltip nobody hovers, and it uses the status line that already exists for exactly this. A note on the surface, since it is a design call: the CANVAS right-click is the offer, this fork's single adaptive menu, and this is not that. A tree row is a different surface, and its menu is three items about the row. Routing tree rows through the offer would mean teaching the offer a selection kind that is not geometry, which is a larger change and not what this report needed. Verified on the rig by the gesture it names: right-click the row, choose Rename, type, Enter -> ['Sketch1'] becomes ['Base profile'] in describe_scene. Gate green: ALL LADDERS HELD — offer table OK, kernel 188 cases / 2532 assertions, engine rungs 1-8, 977-sheet corpus + the heaviest sheets, gesture ladder 98/98, offer ladder 108/108. |
||
|
Tommaso Bianchi
|
1e51b54239 |
Mirror stops destroying arcs, and the Construction box converts what you picked
Two user reports from the same session on the deployed build, 2026-08-23.
FIRST: "if I select a shape (es a circle draw in construction lines) and then I
try to toggle contruction to obtain a full line, does not work". Reproduced: Q
converts the selection and so does the offer's Reference > Construction row —
both run m_keys_sketch['Q'] — but the CHECKBOX, the one control actually
labelled Construction, only ever called set_sketch_construction(), which arms
the mode for the NEXT entity. So the obvious control was the one route that
could not convert existing geometry, and it failed silently while also flipping
the draw mode behind the user's back. It now carries Q's meaning.
Scoped to Select mode, and that scoping is not cosmetic: drawing AUTO-SELECTS
what was just drawn (draw-then-edit), so with a draw tool armed "there is a
selection" does not mean the user picked anything — it means they finished a
line. The first version converted there and turned the box into a trap: arm
construction, draw the axis, click the box to go back to real geometry, and
instead of disarming the mode it converted the axis just drawn. The gesture
ladder's C4 rung does exactly that and reported three construction entities
where it wanted one. In Select mode the intent is unambiguous.
SECOND, and this one destroyed work: "after creation of a circle, a round angled
rectangle and a slot, and mirror of those shapes on a vertical line inside a
outer rectangle, preview is ok but application creates errors: the circle is
mirrored, but rectangle and slot are redrawn as pieces of circles screwing both
the original shapes and the copies." A screenshot came with it, and it showed
more than the words did: the ORIGINALS were wrecked too — the rounded rectangle
was drawn as a four-lobed cloud, each corner fillet having gone the long way
round, and the slot had ballooned into two near-full circles.
Measured on the rig, a slot mirrored about a vertical line:
rails 62.873 / 62.873 -> 2.082 / 62.913
caps r=21.554 sweep=-180.00 -> r=32.214 sweep=-237.66
and all four sources moved, the axis line with them
Cause: confirm_op's Mirror branch bound an Arc copy to its source with a
Symmetric constraint on the CENTRE ALONE. An arc has five degrees of freedom;
pinning two of them leaves the endpoints and the sweep free while the shape's
own coincidences still pull on them, and the solver answers with a different,
internally consistent sketch — which is what a reflex cap and a 2 mm rail are.
A circle came through the same code untouched because a circle HAS no endpoints
to leave free, which is exactly why the failure reads as "circles fine, rounded
rectangles and slots destroyed".
Three parts, and each one is here because the measurement caught the previous
one being half a fix:
1. Arcs are bound by BOTH ENDPOINTS. Endpoints before centre in the ladder:
{p0, p1} is four equations against five DoF and pins the sweep, while
{centre, p0, p1} is six and is refused — the refusal is what silently
degraded the batch to a set that left the sweep free.
2. Every copy is reflected from the PRE-BATCH source, so a batch that disturbs
the sketch cannot hand the next copy already-moved geometry.
3. THE APPLIED RESULT IS THE PREVIEW — checked on the sources AND the copies,
and on violation the whole constraint web is dropped and both halves are
restored to the reflection the preview drew. try_add_constraints rolls back
only when a solve FAILS, and every failure here came from a solve that
succeeded at something else. Guarding only the sources fixed the slot and
left the rounded rectangle's copies at a 13.8 mm rail and a 308 degree cap:
the original was safe and the copy was still wrong, which is half a fix.
The parametric link is kept whenever it provably holds the geometry, and dropped
when it does not. A wrong shape is worse than an unlinked one.
WHY NOTHING CAUGHT THIS: the gesture ladder's mirror rung reflects three
straight LINES. It sat green through the whole defect. C4b now mirrors a slot,
so the reflection has arcs in it, and grades the property the user actually
stated: the copy is the source reflected, the source does not move, and no cap
comes back reflex.
VERIFIED against the user's own scene, rebuilt gesture by gesture on the rig —
outer rectangle, circle, rounded rectangle and slot, a vertical CONSTRUCTION
line as the axis, all 17 entities mirrored in one gesture:
ok the mirror axis is a construction line
ok picked the axis and all 17 entities
ok originals unchanged (moved: [])
ok every copy is the exact reflection (worst 0.000000000)
ok no source arc turned reflex — the 'cloud' failure
ok no copied arc turned reflex (6 arcs checked)
One grader correction worth recording, because it cost a round and would cost
the next one too: a reflection REVERSES ORIENTATION, so a copy legitimately
stores p0/p1 the other way round. Comparing p0 to p0 grades the storage order,
not the geometry, and reported a perfect mirror as an 8.98 mm error. Endpoints
are compared as an unordered pair.
|
||
|
Tommaso Bianchi
|
65e2b6f626 |
The sketch says what to do next, and construction geometry looks like it
User report, 2026-08-23, after using the freshly deployed build: "selection and
removal of existing elements of the 2d sketch is not intuitive, and the bottom ui
text does not illustrate what the user has to do to properly use the selected
tools. Mirror, for example, does not indicate: first select mirror line then
entities to be selected, and there is no UI indication of what is being selected.
normally, costruction lines are dotted." Four defects, all of them in the 2D
vocabulary this fork's charter puts at the centre, and all four fixed here.
snaporca-1c0c (P1) — the prompt was written ONCE, when the tool was armed.
DesignPanel's select_tool lambda set a sentence and nothing ever revised it, so
every step after the first was unguided: Mirror said "pick axis, then entities"
and then never said which of the two you were on; Escape silently downgraded an
armed tool to Select (request_exit is layered: anchors, then tool, then session)
while the line still named the tool you had left; and nothing ever mentioned that
Del removes a selection. The fix moves the line off the arm event and onto the
tool's LIVE state. DesignSketchTool::emit_step_hint() reports (mode, step, picks)
whenever that triple moves, from render() — the one place every state change in
this tool passes through. Putting it there instead of in the thirty-odd branches
of on_mouse is the whole point: a per-call-site notification is a thing the next
tool forgets to add, and it costs three int comparisons a frame. DesignPanel owns
the words, in ONE table (sketch_step_prompt), whose step numbers are the same ones
render() previews and on_mouse consumes, so the description cannot drift from the
code that reads the clicks. Every tool now names the gesture that ENDS it, because
none of them was discoverable: an empty click applies an edit-op or a transform,
right-click cancels it, Esc goes back to Select.
snaporca-vd6v (P2) — Mirror mirrors its axis pick and its target picks into
m_selection, so both painted white and the picture could not answer "what did I
select as what". The edit-op's first pick — Mirror's axis, Fillet/Chamfer's first
line — now paints violet. Violet and not cyan: cyan means SELECTED in this canvas
and nothing else may wear it, a rule this file already carries in writing.
snaporca-imlq (P2) — construction geometry drew as a solid grey line. Every CAD
dashes it, and grey alone does not read as "reference" against the
under-constrained orange. dash_polyline() chops the polyline before it reaches
draw_quad_strip, with the dash and gap in world units scaled by units-per-pixel,
so a dash keeps its size on screen instead of becoming a solid line when you zoom
out and three dashes when you zoom in.
snaporca-oql1 (P2) — Backspace now deletes as Del does. On every laptop this runs
on, Del is a chord and Backspace is what a hand reaches for. The Select-mode
prompt states the rest (Shift-click adds, double-click takes the loop, Del
removes), and the first step of every armed tool names the Esc route back to
Select, which was the invisible half of "selection is not intuitive".
Also, on the same report: the sketch stroke half-width goes 0.6 -> 0.3 mm. At 1.2
mm wide the orange line swallowed a short segment and hid which of two near
parallel lines the cursor was on. One constant, because all twenty call sites of
draw_quad_strip are sketch strokes.
Retired on the way: the on_sketch_selection_changed status writer. It said "N
selected — Delete removes them" while an edit-op mirrored its picks into the
selection, i.e. in the middle of a Mirror gesture, where Delete does nothing of
the sort. on_sketch_step says the true thing for Select and says nothing false
anywhere else. And the live length/angle readout is now APPENDED to the step
guidance rather than replacing it: it fires on every mouse move, so it used to
erase the instruction for the step in progress one move after the click that
started it.
Two false trails, recorded so the next session does not walk them again:
- DesignPanel.hpp deliberately does not include DesignSketchTool.hpp, so the
panel's handler takes the mode as an int and the .cpp casts it back. The
first attempt put Mode in the header signature and the build said only
"expected ',' or '...' before 'mode'".
- The offer ladder failed six properties against a perfectly good binary
because I had relaunched the rig myself without SNAPORCA_KEYTRACE=1, and its
[OFFER] trace lines ARE its instrument. A ladder with no instrument reports
"None", which reads exactly like a regression in the offer. ladder-all.sh
launches it correctly; a hand relaunch must too.
VERIFIED, not merely compiled. Driven on the headless rig with synthetic mouse
and keyboard, and photographed at each step: "Mirror — first click the LINE to
mirror about (a construction line works) · Esc goes back to Select" ->
"Mirror — axis set · now click the entities to mirror · right-click cancels"
-> "Mirror — axis set · 1 to mirror · click another to add or remove it ·
click empty space to apply", with the axis violet, its target white, and the
construction lines dashed while real geometry stays solid.
Full gate green afterwards (scripts/ladder-all.sh, ALL LADDERS HELD):
offer table vs the atlas OK
kernel suite 188 test cases, 2532 assertions
engine ladder rungs 1-8, ALL RUNGS HELD
corpus rung 977-sheet drawing corpus, every 20th -> 49
sampled, 39 gradeable, 39 clean
corpus scale rung the 6 heaviest sheets, all clean
gesture ladder 93/93 properties, real mouse and keyboard
offer ladder 108/108 properties, through the right-click
menu and the verbs behind it
That harness is the reason a UX change of this size can be made in one pass and
believed: 93 + 108 properties are driven the way a person drives the app, and the
977-sheet corpus keeps the engine underneath them honest against real drawings
rather than against my own arithmetic.
|
||
|
Tommaso BianchiandClaude Opus 5
|
3c7105202a |
The offer ladder stops depending on what ran before it
It passed alone and failed inside scripts/ladder-all.sh, twice, on the same property: "right-click with two picked -> None". The diagnostic it now prints said what a screenshot could not — editing=True with an empty selection after two clicks that should have picked two entities. Three rig facts, all about the DRIVER, none of them a product defect: A LEFT-CLICK ON A LINE'S MIDDLE OPENS ITS LENGTH FIELD. The Select branch tests m_live_quotes before it picks, with a ~24 px label tolerance, and a line's Length quote sits at its midpoint — so the click that was meant to select it promoted a dimension and froze the canvas instead. Everything after it landed on nothing. It bit only when the previous step had left that line selected, because live quotes are drawn for the SELECTION: hence passing alone and failing in the gate. Lines are now picked at 0.3 along, clear of the label. A FIELD THAT HAS NOT OPENED YET READS LIKE ONE THAT NEVER WILL. The queue opens each field from a CallAfter, so a driver that looks once, sees nothing and moves on gets frozen by the field that arrives a moment later. keep_as_drawn() now waits for QUIET — two consecutive clear readings — and draw_line_at drains stragglers before handing back. A KEY CANNOT CANCEL A SESSION WHOSE CANVAS IS FROZEN. gui-ladder's enter_sketch dismisses the old sketch with Escapes, which an open field swallows, so the session survived and the four calibration probes landed in it on top of what was already there: "calibration expected 4 points, got 7". Every rung now enters through fresh_sketch(), which cancels through the socket first — that cannot be swallowed. Measured after the fix, in the sequence that failed: gesture ladder 93/93 then offer ladder 108/108, back to back on the same app. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MrMzTpAf78U4NG2M8jfvHY |
||
|
Tommaso BianchiandClaude Opus 5
|
96f9261425 |
The offer table is generated again, and its last verb was unreachable
snaporca-ziam said gen_offer_table.py would silently delete the model-mode "Constrain sketch" row, because that row lived in the generated header and not in tool_atlas.json. Running it found more than that: FOUR rows existed only in the header — constrain, rename, and the three typed- value rows sk_length / sk_radius / sk_angdist — and sk_delete's action had drifted, pointing the sketch row at btn:delete, the FEATURE delete. All five are now in the atlas, so the header regenerates byte-identically from it. Verbs may carry a `note`, emitted as a C++ comment above the row: a rationale written into a generated file is deleted by the next regeneration, which is how this started. snaporca-z8rs (P1), found by making that true: after the atlas held all 92 verbs, the regenerated header differed from the checked-in one by EXACTLY ONE LINE — kOfferVerbCount, 91 against 92. Every consumer loops i < kOfferVerbCount, so the last row of the table was invisible: never listed by show_offer_menu, never findable by mcp_run_verb. The verb that fell off the end is sk_angdist, "Angle / distance…" — the typed-value row for a two-entity selection. On the one selection where you would ask for the angle between two lines, the row that types it was not in the menu. It survived because nothing compared the Sk2Ent menu against the table: sk_angdist accepts Sk2Ent and nothing else, so an off-by-one that dropped the LAST verb was invisible from every other selection. The vocabulary rung now covers Sk2Ent too, and picking the pair taught it one more rig fact — shift-clicking a circle at its +X point grabs the RADIUS GRIP, which replaces the selection with that one entity, so the pair silently collapsed to one and the offer answered SkLine. Correctly, for the selection that actually existed. gen_offer_table.py --check proves header == atlas and changes nothing; it is now the first step of scripts/ladder-all.sh, and the only one that needs no rig. Offer ladder 107/107, gesture ladder 93/93, both on the rig. snaporca-ziam snaporca-z8rs Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MrMzTpAf78U4NG2M8jfvHY |
||
|
Tommaso BianchiandClaude Opus 5
|
1bde448f51 |
Every 2D verb without a shortcut, driven from the offer — and three more defects
The 2D vocabulary is 46 verbs: 22 have a shortcut and the gesture ladder drives them, 24 have none and nothing had ever exercised those. They are reachable only from the right-click offer, so a key-driven ladder could not have touched them whatever it did. Four new rungs drive all 24, and the coverage claim itself is now arithmetic against DesignOffer.hpp (rung O8) rather than a sentence in a comment that rots when a verb is added. The assertions are CONSTRUCTION invariants wherever a click cannot be exact — a regular polygon's sides are equal to 1e-9 and its vertices lie on one circle; a tangent arc's radius at the shared endpoint is perpendicular to the line to 1e-9 (measured cos 5.97e-17); the three clicks of a 3-point circle all lie on it; a circumscribed pentagon's circumradius is the inscribed one's over cos(pi/5), 1.236067977 against 1.236067977. Where a value field opens, the typed value is graded exactly: a moved line travels +25.000000000 in X and 0 in Y, a rotation turns 30.000000000 deg and leaves the length alone, a scale multiplies it by exactly 3, a linear array's pitch is [20.0, 20.0, 20.0] and a polar one's spokes are 60 deg apart all the way round. Three defects found doing it, all fixed here: snaporca-ua9g (P1) — delete_selected left three things behind. The AUTO-EDIT QUEUE, so a queued field opened on a deleted entity and its commit went nowhere: draw a rounded rectangle, delete everything, draw a 2-point circle, type 30 — the field opens, the digits are accepted, and the radius stays 32.992020763. reset_autoedit() exists for exactly this and its own comment says so; it was simply never called from here. The FEATURE GROUPS, whose [begin,end) ranges all shift on a delete, so feature_of() answered with a group the user never drew — survivors are now remapped and any group that lost a member is dropped, the rule the placed quotes already followed. And the SOLVER STATE: no re-solve, so sketch_describe reported dof=16 for a document holding one circle. snaporca-ekt9 (P2) — the read-back could not see three of its seven entity types. Ellipse, EllipseArc and BSpline serialised as a bare type name: no centre, no semi-axes, no rotation, no sweep, no poles. gui-ladder's ellipse rung had to grade the faceted area of the loop at 2e-2 — that tolerance IS the faceting error — and its spline rung could only count entities. Now they carry their parameters, and the ellipse arc's ends are asserted to satisfy (x/a)^2+(y/b)^2 = 1 to 1e-9. Also read-only, and the reason the other two were found at all: sketch_describe now reports the armed TOOL, the count of PENDING anchors, and whether a value field is EDITING. A menu walk that lands one row off arms a neighbouring tool and then draws something plausible — the first run of the authoring rung drew a circle of area 45238.93 and graded it as a rectangle. Every menu pick now asserts which tool it armed, and the polyline rung (a per-segment Length field freezes the canvas after every click) could only be written once the driver could ask whether a field was open. Offer ladder 102/102 -> 105/105 with coverage. Gesture ladder 93/93 and the kernel suite 188 cases / 2532 assertions, both unchanged. snaporca-ua9g snaporca-ekt9 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MrMzTpAf78U4NG2M8jfvHY |
||
|
Tommaso BianchiandClaude Opus 5
|
8c4b05ae9d |
The offer ladder: drive right-click, and fix the two things it found
The gesture ladder proved the TARGET — a complex closed profile, exact in vertices, lengths, arcs
and symmetry, voids correctly attributed. It proved it by arming every tool with a letter key,
which leaves the goal's own MECHANISM untested: the design logic pivots on right-click, and the
verbs offered are supposed to adapt to the element under the cursor. 47 of 86 Design-tab verbs
have a GUI action and no shortcut, so a key-driven ladder cannot reach more than half of them.
scripts/offer-ladder.py drives the menu. It asserts nothing from pixels: show_offer_menu emits an
[OFFER] trace from the same loop that builds the rows (behind the existing SNAPORCA_KEYTRACE), so
what the ladder reads cannot drift from what the user is shown, and the expected row set is
predicted by parsing DesignOffer.hpp rather than transcribed by hand. 25 properties, four rungs:
what each element type offers, that the menu equals the table for four selections AND that the
four differ, a 120 x 80 profile authored entirely through the menu, and a tool with no keyboard
route at all driven from the only door it has.
Two real defects, both found by it, both fixed here:
snaporca-ghcz (P1) — right-click was a black hole while any draw tool was armed. Every draw case
ended with `if (evt.RightDown()) { m_points.clear(); return true; }` and returned true even with
nothing to abandon; on_mouse records that in m_right_consumed and DesignCanvas suppresses the
offer whenever it is set. Measured: with Line armed, two right-clicks in a row produced no menu
and no tool change; only Escape freed it. Same rule snaporca-xmh6 wrote for the selection —
clearing nothing is not a gesture terminator. One shared right_abandon() now consumes the click
only when an anchor was really down; 16 sites, plus Polyline/BSpline (which end a chain, correct
only when there IS one) and Point (which has no anchor at all).
snaporca-lnri (P2) — right-clicking a sketch point offered the empty vocabulary. select_at_screen
tests hit_test_point first and records the hit in m_point_sel, but the offer counts m_selection
only, so a Point entity could never reach the entity branch and SkPoint was unreachable by
construction. A Point IS its own handle, so it is selected as an entity; other entities keep the
handle pick, since a line's endpoint is a drag target, not a vocabulary.
Offer ladder 25/25, gesture ladder 93/93 (no regression), both on the rig. The offer ladder joins
scripts/ladder-all.sh as the fifth rung.
snaporca-ghcz snaporca-lnri
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MrMzTpAf78U4NG2M8jfvHY
|
||
|
Tommaso BianchiandClaude Opus 5
|
12047e4085 |
A bulk sketch_add no longer freezes the next gesture
Draw-then-edit is armed from a jump in the entity count: render() sees n > m_autoedit_seen, selects the last entity and schedules open_primary_autoedit. A scripted add made while a creation tool was armed looked exactly like a drawn gesture, so it opened that tool's value field — and an open field freezes the canvas (on_mouse_impl returns early on m_awaiting_length) and swallows every letter (in_text includes inline_busy()). Measured on the rig: after sketch_add, 'p' + click added nothing (4 entities before, 4 after); one Escape and the identical sequence gave 5. It also explains the selection = [last index] that sketch_describe reported although action_sketch_add never selects anything — the render pass wrote it. Escape worked because it sequences two set_tool calls: the pending CallAfter fires between them, so the second one commits the field it finds open. Arming a tool directly is one call, and the CallAfter fires after it. Fix: resync m_autoedit_seen at the end of add_entities_scripted, so a scripted add is not read as something the user just drew. An already-open field is left alone. Covers sketch_add, sketch_mirror and sketch_offset — the three callers. The scale rung's Escape workaround is deleted, which is the issue's acceptance criterion; it is now the regression test. Gesture ladder 93/93 on the rig. snaporca-j7gc Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MrMzTpAf78U4NG2M8jfvHY |
||
|
Tommaso Bianchi
|
bc1606a4d0 |
Port from snaporca ab22482e40: say why a sheet was skipped, and stop calling an encrypted PDF an engine failure
Over the whole 977-sheet corpus: 767 graded, 767 fully clean, 0 failures. The 210 skips are sheets whose part outline is not a closed stroked path at all (largest loop 5 to 132 mm2, measured), and one of them — MPD133 — is password-protected, which was being reported as an engine ERROR. Both now say what they are. snaporca-j6sr |
||
|
Tommaso Bianchi
|
4693542d0d |
Port from snaporca: the solver's 1024-unknown cliff, and the scale rungs
Two commits carried across (snaporca 579a9a9162, f68613cfc5). Past about 480 entities a sketch had NO constraints at all and said nothing: libslvs declares MAX_UNKNOWNS = 1024 and is handed every entity in the sketch at two params per point, so the whole system came back TOO_MANY_UNKNOWNS and try_add_constraints rolled the entire inferred batch back. From there no dimension could ever be applied. Constraints only couple entities that share a point, so the solver now falls back — only on TOO_MANY_UNKNOWNS — to solving connected components separately and committing all-or-nothing. The auto-constraint pass batches its Horizontal/Vertical constraints instead of one solve each, which is what kept the bulk path fast once solves started succeeding: a 1204-entity load went 1585 ms -> 562 ms. Plus the scale rungs (a thousand-entity plate drawn on by hand; the heaviest real drawings graded and timed), the --step 1 fix that used to select nothing while reporting a clean run, and scripts/ladder-all.sh as the one-command gate. Parity 17 identical / 8 diverging as expected. Kernel suite here: 188 cases / 2532 assertions, including "a sketch past the solver's unknown limit still solves". snaporca-yww4, snaporca-x6v7, snaporca-j6sr |
||
|
Tommaso Bianchi
|
82db99f337 |
Port from snaporca: sketch-only projects save, scripted geometry arrives exact,
and a ladder that draws with the mouse Three commits carried across (snaporca 4ffd60eacb, 421055c2ec, b71216ce0b): 1. A design made only of sketches must survive being saved. CadDocument::recompute returned false with "no solid-producing features" for a document that has no solid, and two callers read that as "unusable": the GUI syncs the 3MF recipe only after a successful recompute, so a sketch-only design was saved with no recipe at all, and deserialize_recipe ends with `return recompute()`, so even a project that carried one was refused on load. Having nothing to build is now a success; a feature that MEANT to build a solid and produced none still fails. DesignPanel::refresh_tree syncs the recipe too, for the paths that call m_doc.recompute() directly. 2. Scripted geometry arrives exact. The Horizontal/Vertical inference window and the endpoint weld window both close to zero for add_entities_scripted; void attribution probes from a point strictly inside each loop instead of from its first vertex. Corpus rung 39 graded / 39 fully clean, was 35 with 6 failures. 3. scripts/gui-ladder.py — 17 rungs, 84 properties, all driven by synthetic clicks and typed values rather than through the socket. Parity 17 identical / 8 diverging as expected. Kernel suite here: 188 cases / 2532 assertions. snaporca-mtav, snaporca-8xg1, snaporca-5hvl, snaporca-730j |
||
|
Tommaso Bianchi
|
05ce2607a8 |
Ladder rung 9: grade the engine against 50 real drawings, not against my taste
Ported from snaporca 5b82c846f3. |
||
|
Tommaso Bianchi
|
1274d97983 |
Sketch: closing a polyline is now a previewed snap, not an invisible bubble
Ported from snaporca 982968b1af. |
||
|
Tommaso Bianchi
|
55a7baf067 |
Sketch usability: no invented geometry, no silent refusals, no stranded field
Ported from snaporca aab4248db8. |
||
|
Tommaso Bianchi
|
1935ebb363 |
Sketch: a tool switch must not leave the rest of the queue armed
Ported from snaporca 8f5adda891. See that commit for the full analysis. |
||
|
Tommaso BianchiandClaude Opus 5
|
fbacdeca7b |
Port: only the visible canvas may consume the 3D-mouse queue
Carries snaporca 9f0a6656bc. Mouse3DController::apply DRAINS the input queue and every BOUND canvas idles and calls it, but a hidden canvas's render() early-returns on _is_shown_on_screen() — so it swallows motion, applies it to the shared plater camera, and draws nothing. The next visible frame jumps by more than one state change. The plater keeps exactly one of its three views bound; the Design canvas binds once at construction and never unbinds, so two canvases drain the same queue. Guarded at the apply site so only the canvas actually on screen takes motion off the queue, whatever happens to be bound, and without touching the plater's view-switching state machine. Reported by exussum12 on PR #15238 as lag and jerkiness in the Design tab against "really smooth on the other tab"; he guessed the mechanism correctly. NOT verified with a device — there is no SpaceMouse here and the rig has no HID, so this is a mechanism traced in source and matched to a user's description, not a measurement. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
942f6c28c7 |
Port: mirror emits a half that continues the chain
Carries snaporca 0231bd5b68. Parity holds: 17 files identical, 8 diverging as expected. A reflection reverses orientation, so mirror_entities now hands the reflected half back reversed in ORDER and flipped per ENTITY — an arc swapping its angles as well as its ends, a spline reversing its control points. Appending it to the source then yields one walkable chain instead of two halves meeting head-to-head, and a mirrored CCW loop stays CCW. This is the producer half of the confusion that cost three defects; the consumers (offset, and the exact loop area) keep their defensive handling, because that is what makes them correct for hand-built and imported sketches rather than only for geometry this function produced. Contract change, carried with the reason: a mirrored line's p0 is the reflection of the SOURCE's p1, and a mirrored CCW arc keeps a POSITIVE sweep — the reflection negates it, walking it the other way negates it again. Both [SketchEdit] cases updated, and a new [SketchProfile] case "a mirrored half continues the original chain" pins the property directly. Kernel here: all tests passed, 2687 assertions in 232 test cases. GUI target builds and links. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
cbbd24dcb4 |
Port the exact loop area, the offset traversal fix, and the 2D sketch ladder
Carries snaporca 572f794c84, d0f9a0052a, 9f7e4e3627 and 3974f8a170. Parity holds: 17 files identical, 8 diverging by their expected counts. EXACT AREA. A loop's area is now integrated entity by entity in traversal order — Green's theorem — instead of being shoelaced over the render polyline, which faceted every arc into 24 chords and lost 2.02 mm2 on a 3706.86 mm2 stadium. 0.054%, invisible on screen, and wrong in a number reported as "the area". OFFSET FOLLOWS THE TRAVERSAL. Offsetting a mirrored profile put one half on the wrong side and split the loop in two, because the chainer only followed p1->p0 links and each entity's offset side was taken from its stored direction. Chains are now orientation-aware, seeded at a free end, offset by `reversed ? -d : d`, and normalised head-to-tail on the way out — so offset is correct for any input ordering and its own output cannot reintroduce the problem. Both are the same underlying lesson, which has now cost three separate defects: an entity's STORED direction is not its direction of TRAVEL around the loop. THE LADDER. scripts/sketch-ladder.py is a graded suite of 2D sketches judged the way a person judges them — VERTEX, LENGTH, ARC, TANGENT, SYMMETRY, CLOSED — with area only as a cross-check, because area is derived and nobody can confirm it by eye. Eight rungs from a rectangle up to MPD5 from the StudyCadCam corpus, a dia 27 x 95 pin reproduced as its revolve half-profile with the R5 fillet tangency solved exactly. Entirely 2D: no extrude or any solid feature. Kernel here: all tests passed, 2681 assertions in 231 test cases, including the new "profile: a mirrored half offsets as one loop, not two". GUI target builds and links. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
510e63dff2 |
Port the sketch usability fixes: Enter/Esc, rename, stale picks
Carries snaporca 95e59289f9, faec177d42 and 20df726ecb. Parity re-verified: 17 files identical, 8 diverging by their expected counts — DesignCanvas.cpp back to 16 and DesignPanel.cpp back to 32, which is the proof each hunk landed on the right side of the FeatFlyout and TAB_ID_PREPARE divergences rather than on top of them. All three answer exussum12's review on OrcaSlicer PR #15238. ENTER/ESC IN THE VALUE FIELD. The field is a borderless always-on-top frame, and whether it may hold keyboard focus is the platform's decision — a borderless NSWindow can never be key, and mutter refuses a re-mapped window. When focus is denied the keys reach the panel instead and the queued-dimension chain (a line queues Length then Angle) cannot be walked. The CHAR_HOOK now forwards Enter/Numpad-Enter/Tab/Esc to the field when it is open and unfocused, and stays out of the way when it is focused. ESC FROM ANYWHERE. Separately and more simply: `dismissable` is false throughout sketch mode because m_active is the FEATURE tool, so Esc fell through to whatever widget had focus. Click any toolbar button or the Construction checkbox first and Esc did nothing at all — the likelier reading of "Esc hardly ever works", and platform-independent. DesignCanvas exposes request_sketch_exit() and the hook calls it whenever a sketch is live, after the inline-field forwarding so an open field still takes Esc first. RENAME. wxTR_EDIT_LABELS plus the two label-edit events write through to CadFeature::name and the recipe, with a Rename verb in the offer and F2. The rebuild is deferred with CallAfter because refresh_tree() destroys the very wxTreeItemId wx is holding during END_LABEL_EDIT — inline, it killed the process. STALE PICKS. set_tool now drops the Dimension tool's first pick, the Constrain picks and m_point_sel, and delete_selected clears the pending dimension reference that could otherwise dereference a renumbered entity. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
fbf858ba47 |
Port the MCP verb surface: run_verb / list_verbs / sketch_set_value
Carries snaporca 39fac9b725. Parity re-verified: 17 files identical, 8 diverging by their expected counts, DesignPanel.cpp still at 32 — the mirrored files were copied and the two divergent ones patched hunk by hunk, so the counts returning to their expected values is the proof each landed on the right side. All 90 offer verbs are now firable by name over the socket, which matters because a deck key can only send a keystroke and 49 of them have no shortcut at all. sketch_set_value calls the same apply_dimension the in-canvas value field calls, so a typed dimension can be asserted with no window manager in the way. Three guards came with it, each confirmed against the source: on_mass_properties bounds-checks m_sel_solid_body (it defaults to -1, and run_verb bypasses the menu grey-out that used to hide that); sketch_set_value validates its value at the boundary because apply_dimension records a driving constraint even for values it refused to apply; and run_verb refuses btn:/fly: verbs that do not apply to the selection while leaving key: verbs alone, so the socket offers exactly what the GUI offers. Dispatch is deferred through CallAfter so no modal verb can wedge the socket thread. GUI target builds and links against the rebuilt deps image. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
5d7fc8c545 |
Port the sketch layer work from snaporca: offset chains, right-click, MCP verbs
Carries snaporca 971320e129, 6b049f0dc6, 4aae782029, 444d59f212, 74cf3d7e54 and the build guards from 597557a6e4. Parity re-verified after every hunk: 17 files identical, 8 diverging by their expected counts — DesignPanel.cpp still 32, DesignCanvas.cpp still 16, which is the proof each hunk landed on the right side rather than being copied over a real divergence. OFFSET OFFSETS THE CHAIN. Per-entity offsetting returned a closed rectangle as four parallel segments that no longer touch, so entities_to_wires gave four OPEN wires and nothing could be extruded. offset_entities now chains by shared endpoints and repairs each seam by mitering the neighbours to their intersection. Second bug, invisible to any single-entity test: +d meant "left of travel" for a line but "radius + d" for an arc regardless of sweep, so a slot outline offset with its straights going one way and its caps the other. The convention is now written on the declaration and pinned by a test. tests/libslic3r/test_sketchprofile.cpp is new and asserts the LOOP rather than coordinates — the property that decides whether a profile can be built, and the one the existing single-entity [SketchEdit] cases cannot see. Its include is catch2/catch_all.hpp here: this fork ships Catch2 v3 while snaporca is on v2, which is why the test files are a tolerated divergence. RIGHT-CLICK PICKS WHAT YOU POINTED AT, so a line's own verbs are offered instead of the empty-selection vocabulary; sk_delete stops sharing btn:delete with the feature tree; and an element's defining number (length / radius / diameter / angle / distance) can be typed, from the menu or from V. TWELVE MCP SKETCH VERBS. The socket had ~40 verbs and none touched a sketch, so the 2D layer could only be exercised by driving a GUI with synthetic clicks. sketch_describe reports each closed loop, the loops it encloses as voids, exact areas, and where a chain is still open; sketch_validate/sketch_heal are FreeCAD's ValidateSketch — find vertices that overlap within a tolerance but carry no coincidence, then weld them AND record the constraint, so a loop closed by floating-point luck becomes one closed by construction. scripts/mcp-sketch-smoke.py is the loop that asserts all of it. Kernel suite on this fork: all tests passed, 2677 assertions in 230 test cases. The GUI target links against the rebuilt deps image (the wxInspector blockage is gone) and the binary carries the new verbs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso Bianchi
|
df45edb13d |
deps image: carry the rig's X runtime itself
Building orcacad-deps from this Dockerfile removes the snaporca-deps base, which is the point (Trap 1: the old image's baked tree was project(Snapmaker_Orca)) — but that base was also where Xvfb, openbox, xdotool and scrot came from. Without them gui-session.sh reports display DOWN and orca-slicer dies with a trace trap on no display. Verified: the session now comes up with display up, wm up, and the Untitled - OrcaSlicer window present. |
||
|
Tommaso Bianchi
|
9764815cc3 |
rig-build: -j12, and a deps image that has wxInspector
Raises the bound from -j8 to -j12: the incident dump measured 1.17 GB average per cc1plus, so 12 in flight is ~14 GB typical, well inside the 40 GB cgroup ceiling that is the real guarantee. Keeps the file byte-identical to snaporca's copy, which the header requires. Dockerfile.deps builds the deps with -j 12 for the same reason, and symlinks deps/build/destdir -> deps/build/OrcaSlicer_dep: this tree installs under the latter name while the orcacad_buildcache volume has the former baked as absolute paths in its CMakeCache. Same tree, two names — without the link, one directory rename costs a full cold rebuild. |
||
|
Tommaso BianchiandClaude Opus 5
|
8906bfa72b |
rig-build: bound the memory a build can take
Both forks ran this script at once on 2026-08-21, each with ninja -j$(nproc)=16. 36 cc1plus held 42 GB of a 62 GB box, the kernel OOM-killed for 2h28m, ssh went unreachable, lightdm was destroyed (2946 session kill events), and neither build produced a single object file. Three bounds, weakest to strongest: a flock on a path SHARED by both forks so they serialise instead of summing; -j8 so the box stays usable while it compiles; and --memory on the container, which is the actual guarantee — a runaway build now dies inside its own cgroup instead of taking the host with it. --memory-swap is pinned equal to --memory because swap thrash is what made ssh hang rather than fail. Kept byte-identical to the copy in the snaporca fork, as the header requires. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
3ad6d2fd50 |
Give Commit to Plate and the bed toggle a keyboard, on a Ctrl+Shift layer
Both were mouse-only: Commit to Plate is a toolbar button bound to wxEVT_BUTTON, the bed is a CheckBox, and neither had an accelerator. That put them out of reach of anything driving the keyboard, and out of reach of a hand that had not already left the model to find them. Ctrl+Shift, because the Shift+letter space is full to the last letter and because the char hook deliberately ignores every Ctrl-combo -- which is exactly what leaves this layer free to claim. P is Plate and B is Bed; neither collides with OrcaSlicer own Ctrl+Shift+S (Save as) or Ctrl+Shift+G (Print plate), and nothing else in the tree binds either. The lookup goes ahead of the guard that drops Ctrl-combos, and nothing already bound changes meaning: a plain Shift+letter still resolves as before, because the new layer only answers when Ctrl is held as well. The bed toggle drives the checkbox rather than the viewport alone, so the control and the view cannot disagree about what is shown, and it says which it did in the status line. Both verified on the running build: Ctrl+Shift+B toggles the grid and the checkbox together, Ctrl+Shift+P commits to Prepare. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
eb66e45b7b |
Design: confine the mapped-frame workaround to GTK, so macOS stops hanging
Reported on PR #15238: on macOS, drawing a corner rectangle and pressing Enter
on the first dimension opens the second field and then wedges the entire
application — no typing, no Escape, dead menu bar, no tab switching, and the
field stays composited over the desktop after minimising. That last detail is
what identifies it: an already-drawn window keeps being composited by the
WindowServer once the process stops answering. The main thread is stuck.
|
||
|
Tommaso Bianchi
|
52d16e4218 | Merge remote-tracking branch 'prfork/cad-mainline' into cad-mainline | ||
|
Tommaso Bianchi
|
2b02a8e3dd |
Design tab: move the CAD sources into their own folder
Review request on PR #15238: "Place CAD-related files (e.g. CadDocument/ GeometryEngine) into a separate folder." src/libslic3r/CAD/ the kernel — CadDocument, GeometryEngine, the four Sketch* units, SketchSolver, ThreadStandards src/slic3r/GUI/CAD/ the tab — DesignPanel, DesignCanvas, DesignSketchTool, SketchInlineEditor, McpControl, generated DesignOffer Pure relocation: no line of logic changes. Two include rewrites follow from it — files that moved re-spell their own neighbours against src/ (already on the include path), and files that did not move pick up the new folder. docs and docs/ux/mockups/gen_offer_table.py follow the same paths. Verified: libslic3r, libslic3r_gui and libslic3r_tests all build, CAD suite green at 2518 assertions in 194 test cases, and the sibling fork builds identically — 17 shared sources still byte-identical, 8 diverging by their expected counts. |
||
|
Tommaso Bianchi
|
5d120921d5 |
deps: build libslvs as a dependency instead of vendoring it in src
Review request on PR #15238: "Move the SLVS to deps if the source code remains unmodified. If any changes were made to the source code, move it to deps_src." It is unmodified — all 20 files under src/libslic3r/slvs were byte-identical to JacobStoren/SolveSpaceLib@4d87045, the extraction of solvespace.com's libslvs. So deps/ it is, fetched by hash like every other dependency. Only the CMakeLists is ours: upstream's builds a demo executable and installs nothing, so deps/SLVS/CMakeLists.txt.in replaces it via PATCH_COMMAND — the same shape deps/OpenCSG already uses. The public header keeps its spelling, so SketchSolver.cpp still says `#include <slvs.h>` and needs no edit. The CI deps cache is keyed on hashFiles('deps/**'), so it rebuilds itself. Verified: dep_SLVS builds and installs, libslic3r links against SLVS::slvs, and the CAD suite is unchanged at 2518 assertions in 194 test cases. |
||
|
Tommaso Bianchi
|
6fc3c99e31 |
Mate connectors: draw the dashed pair line between the two origins
The last unbuilt element of snaporca-wgsc. Two connectors a mate binds are one object with a gap still in it; drawn as two separate frames they read as unrelated, and "which two of these five frames are the mate?" had no answer on screen at all. Dashed, grey, drawn IN WORLD along the segment joining the origins -- so it foreshortens with the model and its length is the gap the mate has left to close. A Fastened mate therefore draws nothing, which is correct: the gap is zero. Screen-constant dash pitch (6 px dash, 4 px gap) like every other gizmo here, with the pitch opening up beyond 400 dashes so a mate across a large assembly cannot emit thousands of segments. Depth test off: the line's job is to say "these two belong together", and it has to say it even when a part sits between the camera and one end. Fed from BOTH sources of polarity truth, the same two the role colours already use: every committed Mate feature (connectors named by feature index), and the live pick of an open Mate card (named by combo ordinal). Only resolved frames are eligible, so an unresolved end draws no line rather than a line to the origin of the world. RIG-VERIFIED on :10 with the fresh binary (/OrcaSlicer/build/src/Release, 2026-08-17 12:43): two imported bodies, a face-and-direction connector on each, Planar mate offset 40. Sampling the segment between the two origins gives a regular dash/gap alternation of 13:10 sample units -- the 6:4 px pitch -- in the stroke grey (107,117,133), over both solids. The grey end keeps its open collar head and the blue end its filled one, so polarity and pair now read together. Refs snaporca-wgsc |
||
|
Tommaso BianchiandClaude Opus 5
|
b4d6abc57a |
Design: draw the mate connector as a bear face, with the disc kept behind a preference
Tommaso's decision (snaporca-x0kd): face orientation is hardwired perception -- a toddler reads
a face's roll and verse with no instruction -- so the connector is a face by default and the
conventional disc + roll quadrant stays, selectable, for users who expect it.
Preferences > Control > Camera > "Draw mate connectors as a face", default ON, key
design_connector_face_glyph. Read every frame rather than latched, so toggling takes effect on
the next repaint -- a look you cannot A/B without restarting will not get compared. Verified on
the rig: unchecking it switches the viewport to the disc live, no restart.
WHY A RELIEF AND NOT A DRAWING. A flat face in the connector's plane foreshortens by
sin(elevation) and collapses at a grazing view exactly like the quadrant it replaces -- measured,
the quadrant falls 89 -> 20 -> 3 -> 0 lit pixels from 47 degrees to edge-on. The relief does not:
its silhouette carries the information. So the glyph is a small shaded solid, painter-sorted,
lambert-shaded against a light fixed in CAMERA space so orbiting does not swing the shading.
THE MUZZLE, AND THE MISTAKE THAT NEARLY LOST IT. It is the only feature standing along +Z, so it
says which way the connector points and it is all that survives edge-on. Two errors on the way:
1. I built its footprint from height*tan(draft) and got a needle. The real base OVERHANGS the
crest at both ends (0.062 nose, 0.034 tail) and that overhang is what makes it a wedge. Base
now lifted straight off the mesh.
2. Worse, I chased fidelity. Scaled honestly the ridge is 11.3 mm on an 83.3 mm face -- 13.6 %
of the width -- and at 22-48 px that is a scratch. Tommaso looked at it and could not find
the muzzle at all, which is the only test that counts. A glyph is a symbol, not a scale
model, so it now gets two deliberate exaggerations, and COLOUR does most of the work:
muzzle share of lit pixels at 90/16/6 deg -- body tone 14.8/11.3/17.5 %, accent gold
18.3/19.2/23.9 %, accent gold at 1.8x width 23.5/25.2/31.2 %.
The accent is the same gold the disc spends on its roll quadrant, so it stays this tab's "here
is the direction that matters" colour. Polarity is still on the Z arrow's head; nothing collides.
A connector whose ROLL COULD NOT BE DERIVED keeps the disc treatment whatever the preference says.
A face asserts a definite orientation, and asserting one for a roll that was never derived is the
same confident lie that got billboarding rejected.
Geometry is emitted from the part by docs/design/mate-connectors/emit_glyph_table.py, not
hand-drawn, so glyph and printed connector cannot drift: 12-vertex outline, two eyes, chin bar,
cheek dot, and the snout wedge. Crest 29.0 mm / 6.58 mm drop / 13.1 deg against the review's
28.3 / 6.61 / 13.1 on the B-rep.
Also fixes extract_outline.py, which walked w.Edges: OCC returns them in storage order, not ring
order, ignoring per-edge orientation, so the outline was scrambled -- 45 points and perimeter
6.380 where a clean ring gives 31 and 3.335. Every measurement in the design notes was re-run.
The correction reversed one earlier finding: handedness does NOT read on its own (5.4/8.0/9.1 %
different from its mirror, not the 32-35 % the scrambled ring produced), so the cheek dot is
required rather than merely nice.
RIG-VERIFIED on Xvfb :12 against a 60x40x10 box with a face+edge connector: the face renders with
both eyes, ears, chin bar, cheek dot and a gold muzzle standing proud; the Z arrow degenerates to
its ring when viewed down the axis; and the preference switches to the disc live.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Tommaso BianchiandClaude Opus 5
|
555af98474 |
Mate connectors: bring the design record and the BearConnector pair into the repo
The connector work has lived outside the code since 2026-08-05, in a workspace repo with no
remote. It is the basis of a decision that now shapes the Design tab, so it belongs here.
docs/design/mate-connectors/
DESIGN_MATE_CONNECTORS.md seven CAD systems surveyed; the frame-pair model this kernel
already matches; sections 8b/8c on the glyph, and section 9's
four open decisions (D1-D4) still awaiting Tommaso.
bear.step the male, Onshape 2026-08-05T08:27Z, md5 faf228326ee3f971
BearConnector_Female*.step/.stl, BearConnector_Cutter.step
built by make_female.py FROM the real male B-rep rather than
re-modelled, so the pocket is complementary by construction
including every deliberate asymmetry. Fit measured at exactly
0.2000 mm, zero interference, mated hosts proven coplanar.
BEAR_CONNECTOR_REVIEW.md the symmetry-group result: identity 81/81 edges, mirror-x 0/81,
mirror-y 0/81, rot180Z 0/81, rot90Z 0/81, diagonal 0/81 at
0.1 mm. Trivial group, so every PARTIAL view fixes orientation.
extract_outline.py, simplify_study.py, relief_sheet.py, handedness.py, make_female.py,
trim_female.py, fit_check.py, verify_trimmed.py, coplanar_test.py + their sheets
THE DECISION THIS SUPPORTS (snaporca-x0kd): the mate connector is drawn as a simplified BEAR
FACE by default, with the standard disc + roll quadrant + Z arrow kept behind a preference.
Face orientation is hardwired perception -- a toddler reads a face's roll and verse with no
instruction -- and no abstract glyph earns that. Measured against the alternative: the disc's
gold quadrant+tick falls 89 -> 66 -> 37 -> 20 -> 3 -> 0 lit pixels as the camera drops from
47 deg to edge-on, and is a shapeless blob by 16 deg.
WHAT THE SIMPLIFICATION STUDY SETTLED (snaporca-wi3z), all measured off the real B-rep:
The eyes are load-bearing. Same outline and muzzle with the eyes removed stops reading as
a face at every size. Whatever else goes, they stay.
45 -> 22 outline vertices with no loss of read at 22 / 32 / 48 px; the muzzle reduces to
one filled triangle. Three marks plus a cheek dot.
Drawn FLAT the face fails exactly where the disc fails: in the connector's plane everything
foreshortens by sin(elevation). Rendered as its real relief instead, lit pixels at 32 px go
164 -> 210 at 16 deg and 69 -> 120 at 6 deg, and the snout ridge stands proud as a profile
rather than smearing. The glyph must be a shaded relief, not an outline.
Handedness already reads without any added mark -- 32 to 35 % of lit pixels differ from the
mirror, and re-registering by best whole-pixel translation returns offset (0,0), so it is
real shape asymmetry. But it reads only BY COMPARISON. A dot on one cheek makes it local:
34.5 / 37.0 / 36.4 %, and unlike uneven eyes (42 %) it does not read as a defect.
Tommaso's calls: it stays a bear, and handedness must read.
The scripts were repointed at the co-located male and extract_outline.py re-run from here to
prove it -- same 45 outline points, same three inner wires, same 3829.5 mm2 back plate.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Tommaso BianchiandClaude Opus 5
|
799f840218 |
Thicken Surface: fill the corners of a closed-loop wall
snaporca-wm4s. Thickening the 4-walled open box (60x60 in plan, 40 tall, no caps) by 5 produced volume 29648.15 where the geometry requires (60^2-50^2)*40 = 44000 — about 67% of it. The corner material at the four vertical edges was simply absent. CAUSE. MakeThickSolidBySimple offsets each face along its own normal and sews; it never extends neighbours to meet, so wherever two faces join at an angle the corner is empty. A flat sheet has no such join and was always exact (18000.000), which is why the defect looked like a measurement artefact. WHY THE TWO EARLIER ATTEMPTS COULD NOT HAVE WORKED. Both switched to ByJoin — plain, then with Intersection/GeomAbs_Intersection — and both returned a shell, not a solid, so the body lost its volume entirely and both were reverted. That is not a parameter problem: in OCCT, BRepOffset_MakeOffset::MakeThickSolid builds a solid only inside `if (!myFaces.IsEmpty())` (BRepOffset_MakeOffset.cxx:1115). Handed an open sheet with no closing faces, it stops after the offset shell and returns it, reporting IsDone() with a non-null shape containing no TopAbs_SOLID. ByJoin hollows a CLOSED solid by removing faces; an open sheet is outside its contract. FIX. Close the sheet, then use the call that mitres: cap the free rims (ShapeAnalysis_FreeBounds -> MakeFace), sew shell+caps into a closed shell, make a solid, and hollow it inward passing the caps as the faces to remove — the caps come back off and leave the wall. Two details, each found by measurement rather than reasoning: * A shell sewn from an extruded sheet carries no guarantee of outward orientation, and MakeSolid does not fix it. Inside-out, the inward offset goes OUTWARD: measured bbox 70x70x40 and volume 339141.59, larger than its own bounding box because the result overlaps itself. A negative GProp mass is exactly that inversion, so it is the test; Reverse() on it. * A SINGLE face has no neighbour to mitre and must keep the BySimple path. It does have a free boundary, so "has free wires" is the wrong question — capping a lone face with its own rim sews a zero-thickness shell and measures 6000 against 18000. Also: IsDone() is not a success test here, since both failed attempts had it true. The code now explores for TopAbs_SOLID and refuses a shell. Tests: new case asserts 44000 with the wall's bbox at 60x60x40 (catching the inverted-orientation shape, which has the right volume nowhere near the right place), plus the flat-sheet control at 18000 that must not regress. Full kernel suite green: 2502 assertions in 187 test cases. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
98135cf529 |
Don't block cloud sign-in because the setup wizard is unfinished
Follow-up to the previous commit, found by driving the app: clicking Login / Register on a fresh install pops "You are currently in Stealth Mode. To log into the Cloud, you need to disable Stealth Mode first." — to a user who has never touched the toggle, whose config says stealth_mode: false. It is the same pre-wizard latch one step earlier. handle_web_request() gates the login commands on get_stealth_mode(), which reports stealth while firstguide/finish is unset, so the app blocks sign-in because the wizard is unfinished — backwards, since signing in is how a user leaves that state. Worse, the escape it offers does not work. "Quit Stealth Mode" writes stealth_mode = false, which was ALREADY false, and never touches the latch: the config is byte-identical afterwards and get_stealth_mode() still returns true. The user clicks the button, believes stealth is off, signs in, and finds every cloud feature still dead. That is the state the reporter of #15239 described. So the login guard now reads the user's OWN setting via the new get_stealth_mode_setting(), not the pre-wizard default. A user who deliberately enabled Stealth mode still gets the dialog and the working Quit button; a user who merely closed the wizard goes straight to the login page. Measured on Xvfb with a fresh datadir (firstguide absent, stealth_mode false): before, clicking Login produced a "Stealth Mode" window; after, it opens the "Login" window directly. And with the previous commit's latch release, a real Orca Cloud sign-in on that same unfinished-wizard profile now runs the whole post-login flow — the sync prompt fires (sync_user_preset lands in the config), the per-user preset folder is created, and Sync Presets syncs with no refusal. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
7d313159df |
Fix cloud features staying off after login when the setup wizard was closed
Reported on #15239: after signing in to Orca Cloud on a fresh install, no sync prompt appears and File > Sync Presets is greyed out with nothing to explain why. CAUSE. AppConfig::get_stealth_mode() returns true whenever `firstguide/finish` is unset, and that flag is written in exactly one place — GuideFrame::SaveProfile(), i.e. only when the setup wizard is COMPLETED. Closing the wizard is what people do today to reach the login (the wizard never offers it, which is #15239 itself), so a new user ends up permanently in a stealth mode they never chose. Every cloud gate keyed on get_stealth_mode() then switches off silently, including: * GUI_App::on_user_login_handle(), which returns EARLY on stealth — so the whole post-login flow is skipped: preset migration, plugin fetch, user-preset load and show_sync_dialog(). That is the missing sync prompt. * the Sync Presets item in both the top menu and the File menu, whose enable lambda was `is_user_login() && !get_stealth_mode()`. That is the greyed item. The result is indistinguishable from real Stealth mode, and nothing in the UI says so, because the one place that DOES explain it — the "Quit Stealth Mode" dialog in handle_web_request() — only covers the homepage login commands. FIX, two parts. 1. The pre-wizard value is a DEFAULT for "the user has not been asked yet", not a setting, so it must not survive the user answering. Signing in to a cloud account is that answer. AppConfig now carries a session-only `m_cloud_logged_in` mirrored from the network agent (on login, on logout, and at agent start so a restored session counts), and get_stealth_mode() consults it before falling back to the pre-wizard default. An explicit Stealth mode setting is untouched and still wins: a user who turned it on deliberately stays offline whether or not they sign in. 2. Sync Presets no longer greys itself out. Both refusal paths already had a message to show — "You must be logged in…" and now one for Stealth mode naming the Preferences toggle — and the enable lambda was making both unreachable. A disabled item that cannot say why is the reason this took a bug report to find. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
8e5d0d195c |
Design: double-click a feature row to edit it, and preview Transform live
snaporca-x1k7 filed three Transform defects. Two were real and are fixed here;
the third does not reproduce and is withdrawn with its measurement.
(1) The feature tree had no ITEM_ACTIVATED binding at all, so double-clicking any
row only highlighted it. Double-click is the documented edit gesture elsewhere
(a committed sketch opens that way on the canvas), which made every feature look
dead until the user found the Edit button in the section header. Bound to
on_edit_feature(), so the gesture now works for every feature type, not just
Transform.
(3) The Transform card's typed fields called refresh_preview(), but preview_fields
returns {} for Transform and the solid-preview path has no ghost to build for a
feature that moves an existing body — so typing a distance changed nothing on
screen until Confirm. The fields now drive the same channel the gizmo drag already
uses: the body's display transform. In EDIT mode the committed transform is
already baked into the kernel geometry, so the preview undoes it first; without
that term, re-opening a committed Z=20 and typing 40 would show the body at 60.
(2) NOT REPRODUCED. Dragging a rotation ring does fill the field: a tangential
drag on the red ring gave Rotate axis = X, Angle = 27.44 deg, plus the translation
that rotating about the card's pivot implies (Y 17.60, Z -62.11). The original
reading came from a drag that never grabbed the 7 px ring; this run took its
candidate points from the rendered ring pixels themselves and 6 of 6 answered.
Rig-measured (docker snaporca-gui, Xvfb :10, llvmpipe), vertical screen shift of
the body by image correlation:
commit Translate Z 0 -> 20 : +140 px
double-click the Transform row : +0 px, and the card re-opens showing 20.00
step the re-opened card 20 -> 40 : +142 px (not +280 -> the undo term is right)
Cancel : +0 px vs the committed frame, residual 0.46
Add mode: stepping Z moves the body immediately (viewport diff bbox
200,143-1181,999); Cancel puts it back with only the status strip differing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Tommaso BianchiandClaude Opus 5
|
f4a0bf8845 |
CAD: give Rib a shortcut, completing the pick-the-line work (snaporca-3648)
Ported from snaporca ea0e11e49d. See that commit for the acceptance measurements. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
dcbda7d42c |
CAD: deliver the picked sketch ENTITY to the panel, and point Rib at it (snaporca-3648)
Ported from snaporca 94b6b564de. See that commit for what is and is not measured. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
315a35e2ea |
CAD: Sweep path and Loft profiles fill from a viewport sketch pick (snaporca-ysm2, e1p item 6)
Ported from snaporca 314d30c660. See that commit for the measurements. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
7920e55413 |
CAD: give the keyboard back when the action bar hides (snaporca-ehrm)
Ported from snaporca ace5778d4c. See that commit for the measurements. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
31548a230d |
CAD: Mirror takes its body from the viewport (snaporca-gtd3, e1p item 6)
Ported from snaporca 2516961a32. See that commit for the measurements. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
2643c778dc |
CAD: Boolean takes its two operands from the viewport (snaporca-310o, e1p item 4)
Ported from snaporca 572eb56d0e. See that commit for the measurements. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
dd6363f536 |
CAD: clicking a reference plane's label selects THAT plane (snaporca-uw3c)
Ported from snaporca 373ef325d8. See that commit for the full rationale. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
920f0bd126 |
CAD: keep the pick trace, stop paying for it when it is off (snaporca-txp8)
Ported from snaporca 3710d34568. See that commit for the full rationale. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
457610108e |
CAD tests: pin the sheet-body mass properties with the rig's own numbers (snaporca-lu27)
Ported from snaporca 35befd965c. See that commit for the full rationale. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
4c8c93b512 |
Design: keep the inline dimension frame mapped across queued fields (snaporca-p8uw)
Ported from snaporca e4e0e21581. See that commit for the full analysis. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso Bianchi
|
d9abadc88f |
Revert "CAD: type a sketch dimension without clicking the field first"
This reverts commit
|
||
|
Tommaso BianchiandClaude Opus 5
|
ab15f386e4 |
CAD: type a sketch dimension without clicking the field first
On a Wayland session the in-canvas value field never took the keyboard focus, so after drawing a rectangle the first keystrokes went nowhere and the field had to be clicked before a number could be typed. open() already did Show, Raise, SetFocus on both frame and control, SelectAll, and re-asserted all of it in a CallAfter — none of it works here, and no amount of re-asserting would: under Wayland a client cannot focus itself, and mutter ignores gtk_window_present() without an activation token as focus-stealing prevention. The earlier fix recorded in this file (dropping wxFRAME_FLOAT_ON_PARENT, whose GTK _UTILITY_ hint made an xrdp session refuse focus) addressed a different compositor. Stop needing WM focus. The canvas keeps the focus and feeds the field: SketchInlineEditor::feed_key() types into the control directly — Enter commits, Esc cancels, Backspace/Delete edit, digits and '-' '.' ',' are accepted, and anything else is handed back so a stray letter cannot vanish into a numeric field. A m_fresh flag reproduces the SelectAll semantics the field already had, so the first digit replaces the prefill. It returns false when the control genuinely holds the focus, so X11 keeps wx's normal routing and no character is typed twice. The CHAR_HOOK gates on the editor's own is_open(), NOT on inline_busy(). inline_busy is a freeze flag for the sketch tool: cleared on commit, re-set only when the next queued field opens, with a CallAfter between them. Gating on it left a window where the field was on screen and the flag was false — typing worked for a rectangle's Width and not its Height. VERIFIED at the machine on behemoth: typing the first dimension directly, with no click, works. NOT yet confirmed: the Width -> Height handover; the is_open() gate is diagnosed from the handover code, not observed. The hook's SNAPORCA_KEYTRACE=1 switch logs each key with the focused widget if it needs chasing further. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
614824ce89 |
CAD: right-click in a sketch offers verbs for what is selected, instead of for nothing
Select a line in a sketch, right-click, and every sketch verb was greyed: Trim,
Extend, Fillet, Chamfer, Offset, Mirror, the arrays, Constrain. The menu was
right and the selection was gone — two independent faults, each of which hid
the other.
FIRST, the Select-mode RightDown branch called clear_selection() before handing
the click back. Handing it back is correct: the m_right_consumed flag means "the
tool USED this right-click", and a plain right-click is not a gesture
terminator, so the offer should open. Clearing first is not: the offer describes
WHAT IS SELECTED, so wiping the selection guaranteed it could only ever describe
nothing. Deselection keeps its own gesture — left-click on empty space, a few
lines above in the same handler.
SECOND, offer_selection_kind() returned SkNone for every sketch state. The offer
table has always carried verbs for a selected line, arc, point or pair, but
nothing ever RETURNED those kinds, so fourteen rows were gated on selection bits
no code path could set. Classify the selection instead: SkLine / SkArc / SkPoint
/ Sk2Ent, via a first_selected_type() accessor on the tool and two forwarders on
the canvas.
Either fix alone measures as a failure — the classification is handed an empty
selection, or the preserved selection has no kind to match — which is why both
land together.
This is the second half of the report behind
|
||
|
Tommaso BianchiandClaude Opus 5
|
eb52972a8e |
CAD: the offer menu speaks one language, not two
On a non-English desktop the offer menu came out mixed: "Create / Add material /
Rimuovi / Fillet / chamfer / draft / Repeat / Transform / Reference / Modify",
and under Modify, "Elimina" beside "Constrain sketch".
Nothing was mistranslated. The row names went through a bare wxGetTranslation(),
which searches EVERY loaded catalogue — including wxWidgets' own wxstd. That
catalogue is loaded in the desktop's language whether or not the application has
one, and it happens to contain exactly two of our eight row names:
wxstd it: 'Remove' -> 'Rimuovi', 'Delete' -> 'Elimina'
Create, Add material, Repeat, Transform, Reference and Modify are not wx
vocabulary, so they stayed English. Two words in one language, six in another,
in the same menu — and the same trap is set for every other locale wx ships:
Supprimer, Löschen, Eliminar.
Name the domain: wxGetTranslation(s, SLIC3R_APP_KEY). These strings are now
translated by our own catalogue or not at all, which is consistent either way.
Left deliberately alone: the accelerator still renders as "Canc" rather than
"Del" on an Italian system. That is wx naming the physical key, and on an
Italian keyboard the key really is marked Canc — telling that user to press
"Del" would name a key they do not have.
Verified on the rig with LANG=it_IT: the menu now reads Remove and Delete, and
the submenu shows "Delete Canc" beside "Constrain sketch".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Tommaso BianchiandClaude Opus 5
|
3eb6e5d608 |
CAD: constraints are reachable from the offer menu, not only from a toolbar icon
A user evaluating the Design tab against Onshape reported that "adding constraints seems to be missing" — with nineteen constraint types and a solver shipped behind it (OrcaSlicer PR #15238, exussum12). They were not wrong about what they could see. The only ways in were an icon-only toolbar button whose tooltip you have to hover to read, and an offer row gated on sketch_mode with a sketch ENTITY selected, filed under "Reference". Right after finishing a sketch — the moment you want to constrain it — neither was in front of the user, so a shipped headline feature read as absent. Add a model-mode row: "Constrain sketch", offered under Modify when a sketch region is selected, routed through the new btn:constrain verb action. on_begin_constrain() also gains a fallback to m_sel_sketch_feat. The offer reaches it from a SkLoop selection, which carries no TREE selection, and the function read only tree_selection() — so the new row would have answered "Select a sketch in the tree first" about a sketch the user had visibly selected. It now adopts the region's owning sketch and syncs the tree to match. Verified on the rig: draw a rectangle, finish the sketch, click the region, right-click -> Modify -> "Constrain sketch" enters Constrain mode with "Pick 1-2 lines, then a constraint" and the Constraints (8) card listing the sketch's inferred constraints. That path did not exist before. Does NOT address the other half of the report: there is still no Pierce constraint, so a sweep profile cannot be tied to its path. Tracked separately. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
9013f530fa |
CAD: a sheet body reports no volume, instead of a confident wrong one
mass_properties on an open shell returned volume 96000 with an inertia diagonal of [-4.2e7, -4.2e7, -6.9e7] for a 60x60x40 four-walled box — negative principal moments, which no real body can have. BRepGProp::VolumeProperties integrates the divergence theorem over whatever faces exist; on an open shell that is not a volume at all, and the old code hid the only obvious tell by taking std::abs() of the mass. "valid: true" then asserted the number was trustworthy. This matters because mass_properties is what an agent or a user reaches for to confirm a cut removed the right material. Silent nonsense there means the check passes on garbage. MassProps gains is_solid. For a sheet we compute surface area only — that stays exact — and report volume 0 with the inertia left zeroed. The MCP verb returns is_solid plus a note saying volume and inertia are not defined for an open shell; the GUI's Mass command says "sheet body — N cm² of surface, no volume" rather than quoting material that is not there. Verified on the rig: the sheet now returns volume 0.0, surface_area 9600.0 (exactly 4 x 60 x 40), is_solid false. The solid controls are unchanged and exact — a 60 mm cube reports 216000.0 and 21600.0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
1545fb7946 |
CAD: an armed Plane or Axis pick captures the face, instead of escalating to the body
Clicking a face that already happened to be selected, while a Plane or Axis pick was armed, read as a repeat pick: the click escalated to "whole body", the capture was lost, and the card's label stayed "(none)" with nothing on screen to explain it. On a cube it is easy to hit — the face under the cursor is often the one already selected from the previous step. The capture path in on_solid_picked already restores the flag for all three tools, and reset_plane_refs()/reset_axis_refs() restore it when a pick is abandoned — both were written as if the arm side disabled escalation. Only CoordSys actually did (that was snaporca-u0wd). Plane and Axis never had it. Verified on the rig: Midplane on a 60 mm cube now captures Face A (#5, top) and Face B (#3, side) on the FIRST click each, and the resulting plane renders as the 45-degree bisector between them, which is what a midplane of two perpendicular faces should be. Before this, the first pick escalated to the body and Face A stayed "(none)". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
f6f2edb906 |
CAD: the Plane card refuses a method it cannot build, instead of quietly building another one
Every method in CadDocument's plane dispatch falls back to offset_angle_plane() when its references are missing. Picking Tangent and confirming with nothing selected therefore produced an OFFSET plane, announced as "Plane added — pick it as a sketch plane". The user asked for one construction and silently received a different one, with nothing on screen to reveal the substitution. Validate at the GUI boundary instead: Angle needs an edge, Midplane two faces (and not the same face twice — that yields a plane coincident with the face, which is well-defined and useless), Tangent a face, Two-edges two edges. Offset and Coincident are unchanged: both are meaningful with no reference, since they fall back to the base plane by design. on_add_plane() now returns false when it refuses, and confirm_tool() skips close_tool() in that case — a refusal that also threw away the picks the user had already made would be worse than the bug. The kernel keeps fallback_offset(): it must return something. It should just never be reachable from a user gesture without a warning. Verified on the Xvfb rig: Tangent with no pick refuses and creates no feature (it created one before), the card stays open with the type preserved, Midplane with no faces refuses with its own message, and Offset with no picks still creates a plane as it always did. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso Bianchi
|
9a5e9dfc36 |
CAD: the wheel scrolls the card panel, it does not edit the field under it
wxSpinCtrlDouble takes the mouse wheel whenever the pointer is over it. A card taller than the panel therefore could not be scrolled past without silently incrementing whatever field the cursor happened to be over — measured on the rig: eight notches over the Coord Sys card turned an X hint from 1,00 into 6,00 while the panel did not move at all. The same gesture over an Extrude distance, a Hole diameter or a mate Offset is a silent model change made by someone who believed they were navigating, and nothing on screen reports it. Every spin in this panel comes from one factory, so the guard goes there: an unfocused spin hands the wheel to its parent, and the scrolled cards panel gets it. A spin the user has deliberately focused still takes the wheel, which is the one case where editing is what was meant. Verified on the rig with an Extrude card: eight notches over an unfocused Distance leave it at 10,00; clicking into it first and scrolling takes it to 13,00. |