mirror of
https://github.com/OrcaSlicer/OrcaSlicer.git
synced 2026-09-26 02:11:18 +00:00
648b930e7575b5805b25ae3d9cec4b8100c998e9
17
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 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. |
||
|
SoftFever
|
41365736ff | Fix the Windows build | ||
|
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
|
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
|
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
|
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
|
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
|
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. |