mirror of
https://github.com/OrcaSlicer/OrcaSlicer.git
synced 2026-09-18 14:32:36 +00:00
41365736ff1a3daf99d2a802d8545c0f46957255
37
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 SoftFever
|
0aeb6df122 | Merge branch 'main' into cad-mainline | ||
|
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 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 Bianchi
|
1274d97983 |
Sketch: closing a polyline is now a previewed snap, not an invisible bubble
Ported from snaporca 982968b1af. |
||
|
ExPikaPakaandSoftFever
|
5ed56eb876 |
Cache system presets to eliminate startup and wizard load times (#14217)
* Add caching system for presets * Removing user\bundle serialization and keeping it only for system presets * Integrate caching into WebGuideDialog which speeds up time of SetupWizzard and PrinterSelection dialog * Add CI\CD step to prepare cache file in ahead of time so user does not need to wait * Add partial cache generation when only one of the vendros is changed to speed up recalculation time * Handle corrupted files * Add cache to GuideDialog as previos version didn't work as expected * Add inspecting tool and fix CI cache generation * Generate cache per vendor * Simplify code by mergin it in PresetBundle * Simplify code a bit more * Add cereal serialize() to VendorProfile, PrinterModel, Preset, and Semver * Remove CachedPrinterModel/VendorProfile/Preset mirror structs from VendorCache * Fix use-after-free in CallAfter lambda; replace raw thread pointer with unique_ptr * Use get_vendor_cache_key() to match cache keys written by the app * Remove BOM added by VSC * Skip invalid vendors * Remove leftover cache file * Fix build for windows arm64 * Revert json cache back * Update check for stale cache * Serealize all value fields for Preset class to minimize regression later * Minimize field duplication by moving Cache thing into PresetBundle * Add tests for Cache system * Add a bit more tests * Merge branch 'main' into feature/cache_profiles_and_optimize_loading_speed * Rvert from per-verndor to single cache file Replace N per-vendor .cache files with a single system_presets.cache that holds all vendors and presets in one serialized blob. Cache load is now all-or-nothing: on hit all vendors are applied from the bundle (sub-second); on miss all vendors are parsed from JSON and a fresh bundle is written to the user cache dir. Invalidation is driven by bundle_key - a sorted concatenation of all vendor JSON version strings. Any vendor update invalidates the whole cache and triggers re-parse on next launch. Guide wizard (WebGuideDialog) loads the bundled cache into a plain PresetBundle instead of a separate VendorGuideData struct, removing the duplicate data model. generate_system_cache simplified from a per-vendor loop to a single save_system_presets_cache() call producing one output file. * Transfer all Preset fields from cache via move assignmet apply_vendor_preset_group was copying fields manually and missed bundle_id, user_id, base_id, sync_info, updated_time, key_values, ini_str. Replace field-by-field copy with move assignment of the fully-deserialized Preset, then restore the vendor pointer which is excluded from serialization. * Ignore cache for future * Remove not used files * Ship one preset cache per vendor in place of the profile JSONs Each vendor's system presets serialize into a single <vendor>.opc built at package time, and a shipped build carries that file alone — the profile JSON and its sub-file tree are pruned. The vendor loader, the setup wizard's profile list and the resource installer all read a vendor through its cache, falling back to parsing whenever one is absent, stale or unreadable, so the cache stays an optimization and never a source of truth. Caches hold presets in source form and resolve inheritance at load, through the same code the JSON path uses. * Make the preset cache self-describing and load each vendor from the system folder alone The cached DynamicPrintConfig is keyed by name, through a per-file dictionary of the distinct opt_keys, the type each was written as, and the distinct enum value names, instead of by serialization_key_ordinal — a position assigned by declaration order at static init, where inserting one option shifts every later ordinal and the lookup then succeeds on the wrong option. Because a name-keyed payload drops the options this build cannot place rather than being rejected wholesale, the schema fingerprint goes, and with it the two fallbacks that existed only because an installed cache died on every app upgrade: the second lookup tier into resources/profiles and the parse fallback to the same place. A vendor is loaded from <data_dir>/system/ and nowhere else, as on main — which is what makes the app write its .opc files there again. * Simplify the preset cache internals after review * Use the shared temp-dir helper in the preset bundle loading test * Bound stamp string reads in the preset cache * Speed up the setup wizard with a profile-data cache The wizard's per-vendor fast path threw on vendors present only in resources, falling back to a ~29 s raw JSON scan on every open. Each vendor now loads from the directory it was found in, and the derived model/machine/filament/process catalog is cached whole in <data_dir>/cache/wizard_profile_data.json, stamped by each vendor's name and version - a fresh cache makes an open one file read, with no bundle built and no presets installed (~0.2 s vs ~2 s). * Remove debug SVG dump from a geometry test * Move the per-vendor cache file format into PresetCacheFormat * Move the vendor install helpers from PresetBundle into Utils * rename * fix flatpak * change cache version to 1 --------- Co-authored-by: SoftFever <softfeverever@gmail.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. |
||
|
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>
|
||
|
SoftFever
|
030e5f469e | Merge branch 'main' into cad-mainline | ||
|
Tommaso BianchiandClaude Opus 5
|
606026a920 |
Home: axonometric view, fitted
DesignCanvas::set_view() and fit_view() were both written and then never called from anywhere in the tree. The Design viewport has had no way back to a standard view since it existed: no key, no button, nothing but orbiting by hand until the model happens to drift into frame. That is worse than a missing convenience. A camera left pointing along the bed plane renders a scene that looks exactly like a failed renderer — geometry present, nothing visible — and an hour went into blaming the software GL stack before the real cause turned out to be two uncalled functions. Home rather than a letter: every letter A-Z is already a Shift+letter tool shortcut. Home is also the reset-the-view key most users arrive with. The dispatcher needed no change, it keys on the raw wx keycode. set_view() already does select_view + zoom_to_volumes, so this is fit and orient in one call. Doc row added to the View toggles table in docs/design_tab.md. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso Bianchi
|
6c59898ac0 |
Design: pointing at part of a body is pointing at the body
Tommaso: "i deleted a body using rubber band selection, but this is not intuitive as all the ux revolves around clicking". Correct on both counts, and a correction to what I said last round: the rubber band IS implemented and shipping (pick_bodies_in_rectangle, m_rubber, the drag branch in on_mouse). What is unbound is whole-body picking via CLICK; I read the comment about the click path and wrongly generalised it to the gesture as a whole. The handlers were never the problem either. Move, Mirror, Cut, Mass and Colour all resolve their target through selected_body_default() / m_sel_solid_body, and that is already set when you click a FACE — level >= 1 records the body. They would have worked from a click all along. The only thing keeping them out was the atlas gate: accepts listed body_solid and no face kind, so offer_selection_kind() returning FacePlanar filtered the rows away. This is therefore an atlas-only change, no handler edits. Cut, Split, Mirror, Transform, Mass and Colour now accept face/edge/vertex as well, matching what Delete Body already did. Edges and vertices are included deliberately, not just faces: a click resolves to a vertex, an edge or a face depending on where inside the pixel it lands, so accepting only faces would make Move vanish whenever you clicked near a corner — a flicker that reads as a bug and gets reported as "sometimes it works". NOT widened: Extrude on a face means push/pull THAT face, and Thicken consumes the face you point at. Both have genuine face-specific meaning, so widening them would change what they do rather than where they can be reached from. The rubber band keeps its job — it is still the only way to take a body without also naming one of its faces. It just stops being the only door. Verified on both rigs from a plain face click: Transform > Move opens with Body = Extrude2 (resolved from the face pick), Modify > Edit / Delete Face / Colour / Delete Body, and Reference > Mass. |
||
|
Tommaso Bianchi
|
b2654ebd8a |
Design: a body knows what made it, so "Delete Body" can exist
Reported by Tommaso: select a body, and there is no Delete in the offer. Two independent faults stacked behind that. FIRST, clicking a body never selects the body. Whole-body picking is deliberately unbound (DesignSketchTool.cpp) pending the rubber band, so a viewport click only ever yields Face/Edge/Vertex. The offer therefore saw face_planar, and "delete" accepted body_solid but no face kind, so the row was filtered out entirely — while the status line read "Body 1 face 0 selected", which actively teaches the wrong model. SECOND, even selecting the body from the Bodies list, Delete refused in red: "Select the FEATURE that created this body". CadBody had no link back to its maker, so the offer was advertising a verb it could not perform — worse than the action:null rows fixed earlier this session, because this one is ENABLED and its refusal reads like user error. CadBody::source_feature fixes the second. It is stamped in ONE place, the recompute loop, and the rule is just "still unset?". That is sufficient because of an invariant worth stating: no feature ever replaces a whole CadBody. Every in-place op writes only .shape (boolean, cut, mirror-fuse, transform, dress-up — all 8 sites checked), so a body keeps the stamp it was born with; a consumed body is erased outright, taking its stamp with it; and the only bodies still at -1 are the ones the current feature just pushed. A feature type added later needs no change here as long as it keeps to that invariant. "Delete Body" fixes the first, sitting beside "Delete Face" in Modify and reachable by pointing at any face/edge/vertex. The two names cannot be confused, and "delete" gave up the body kinds so both can never appear for one selection. Deleting a body removes the feature that made it, which is a real edit to the recipe, so it asks first and NAMES the feature — a body vanishing from the viewport is not evidence of which feature went, and this is the one action here that cannot be eyeballed. Multi-body delete is NOT offered. bodies_2 was in the first draft of the verb; the handler deletes exactly one body, so a two-body selection would have silently deleted whichever was m_sel_solid_body. Caught before it reached a binary, at the cost of one rebuild. Verified on BOTH rigs, full round trip: click a face -> Modify > Delete Body -> "Delete Extrude2?" -> body gone, Sketch1 correctly left behind, panel falls back to the idle hint -> Undo -> Extrude2 and Body 1 restored. |
||
|
Tommaso Bianchi
|
cfc2555c3a |
Design: a verb's address is data, so the toolbar widget can stop existing
snaporca-7ih's remaining half. Both flyout factories registered their verbs INSIDE the widget-building loop, so the ~40 retired tool buttons had to be constructed and then Hide()n: skipping construction would have deleted 42 offer verbs (26 fly:<family>#<row> + 16 Shift+keys) while their rows still rendered and did nothing when picked. Register first, build second. The addresses are pure data; the widget is one door onto them, not their owner. A family absent from kBarKeep now returns before any wxWindow is made. The keep-list stays a one-line data decision, not a structural one. And close the class of bug for good: the constructor now verifies, once, that every verb the atlas marks wired resolves to a real registration, logging each break and asserting in debug. Rows that render and do nothing have shipped three times (edit_feature and sk_move with action:null, then this) and are invisible from either side alone. Verified on the snaporca rig by walking the offer, not by reading the code — all four at-risk address kinds run with no widget behind them: fly:design_rect#2 drew an OBLIQUE rectangle (the third variant, not the family's first), key:S+E opened Extrude with its 10 mm gizmo, fly:material#4 opened Thicken. Hover hints, icons and nesting intact. This fork is code-identical here bar the two permitted DropDown divergences; it still owes a build of its own (snaporca-5pl). Two hints were wrong and are fixed: Cut said "Split the body with a plane", colliding with the Split verb one row away and pointing at a card for a value the canvas already offers as a draggable arrow; Split never said its plane comes from a picked face. Also, because it blocked the verification and will block the next one: gui-session.sh killed by full path while its own app_pid() matched by basename, so a differently-pathed instance survived, held the single-instance lock, and got reported as a healthy session — a Jul-30 binary nearly passed as this build. It now kills by basename and prints which binary is actually on screen. Traps 6 and 7 documented. |
||
|
Tommaso BianchiandClaude Opus 5
|
96816f725c |
Design: every offer verb has a hint, shown on hover — and the status line wraps
Mirror of snaporca 2b3e890165 (DesignPanel.cpp applied as a patch; parity 30 / 16, shared files byte-identical). All 86 verbs now carry a hint: 55 extracted from the C++ tool definitions so the offer and the armed-tool hint cannot drift, 31 written by hand. One wxEVT_MENU_HIGHLIGHT binding shows the hovered verb's hint in the status line. The generator asserts that no wired verb lacks one. Also: all 200 status writes go through set_status(), which wraps instead of clipping at the panel edge; and the empty-document hint is called from on_tab_shown() as well, since after_tree_edit() never runs on a freshly opened tab. Verified on the rig. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LyRwbuq6fjn3VV9U9UvhBM |
||
|
Tommaso BianchiandClaude Opus 5
|
a535b0cb76 |
Design: the offer draws each verb's icon — set the bitmap BEFORE Append, not after
Mirror of snaporca bcab67f8ce (DesignPanel.cpp applied as a patch; parity 30 / 16, shared files byte-identical). tool_atlas.json now names an icon for 80 of 86 verbs, derived from the toolbar's own definitions rather than invented, and every one of the 54 distinct names was checked to exist in resources/images first. The first attempt drew nothing despite a green build: wxGTK builds the GtkMenuItem inside Append() and reads GetBitmap() there, so setting the bitmap on the returned item is a silent no-op. append_offer_item() constructs, sets, then appends — the same order Orca's own append_menu_item() uses. Verified on the rig. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LyRwbuq6fjn3VV9U9UvhBM |
||
|
Tommaso BianchiandClaude Opus 5
|
447c71a0d2 |
Design: Text and SVG join Create — they were excluded on a premise that is not true
Mirror of snaporca 6724ea27c5 (DesignPanel.cpp applied as a patch; parity 30, shared files byte-identical). chrome_only's rule is "acts on the DOCUMENT, not on a selection". Text and SVG both call add_imported_sketch(), which drops the art on a picked solid face via SketchPlane::from_face() — a selection-consuming profile creator, like Sketch. Now sk_text / sk_svg in the sketch half's Create row, where their toolbar buttons already sit. Verified on the rig: Create ends Point, Text, SVG. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LyRwbuq6fjn3VV9U9UvhBM |
||
|
Tommaso BianchiandClaude Opus 5
|
273cf067e8 |
Design: record that Shell stays in Remove — decided, not overlooked
Mirror of snaporca e2ef3018cd. Data only, and only the `why` prose in two slots — the generated DesignOffer.hpp is byte-identical, so there is nothing to rebuild. Ratified 2026-08-01: the offer deliberately splits the toolbar's dressup family. Shell hollows a solid so it sits in Remove; Delete Face edits an existing solid so it sits in Modify. Recorded in both slots' `why` so either half explains the split. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LyRwbuq6fjn3VV9U9UvhBM |
||
|
Tommaso BianchiandClaude Opus 5
|
f6e6cd83c1 |
Design: the fillet row is named for the tools it actually holds
Mirror of snaporca 352cf1c259 (data only — tool_atlas.json + the regenerated DesignOffer.hpp; both byte-identical across the forks). "Fillet / chamfer / draft" rather than naming shell too: Shell is in Remove and Delete Face in Modify. Only the toolbar's dressup dropdown groups all five. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LyRwbuq6fjn3VV9U9UvhBM |
||
|
Tommaso BianchiandClaude Opus 5
|
0c2b643b0b |
Design: the card says which tool it is, and "Dress-up" stops being a word we use
Mirror of snaporca 3677937964 (DesignPanel.cpp applied as a patch; parity 30, shared files byte-identical). The card header read "Fillet 1" over a chamfer because the offer's Chamfer address opened the tool before setting the type, and open_tool() titles the card from that combo. Choose first, then open. "Dress-up" removed from the offer row (-> "Fillet / chamfer"), the card field (-> "Type", it was a label reading Dress-up whose value said Chamfer) and the toolbar tooltip. Verified on the rig: header "Chamfer 1", field "Type: Chamfer", row "Fillet / chamfer". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LyRwbuq6fjn3VV9U9UvhBM |
||
|
Tommaso BianchiandClaude Opus 5
|
3c998b8a62 |
Design: a tool's options come from the tool, not from a card on the left
Mirror of snaporca 6d5510734b (DesignPanel.cpp applied as a patch; parity re-checked at 30 lines, shared files byte-identical). Polygon's Sides/Circumscribed card is deleted — the choice is made in Create > Polygon, which names the counts and the two fits, because the side count cannot be recovered after drawing. Dress-up, Combine and Pattern were single verbs hiding several behind a combo and now name each one in the offer. Fixes fillet and chamfer both carrying key:S+F, which made the offer's Chamfer open a Fillet. Built green and verified on the rig: the Dress-up card opened from Chamfer reads Chamfer. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LyRwbuq6fjn3VV9U9UvhBM |
||
|
Tommaso BianchiandClaude Opus 5
|
d1d61ce997 |
Design: every sketch tool has an address in the offer, not just its family
Mirror of snaporca 0c83f59f13 (DesignPanel.cpp applied as a patch, not copied, so this fork's 30 permitted divergent lines survive; parity re-checked at 30/16 with the shared files byte-identical). The sketch dropdown never registered "fly:<family>#<row>" addresses the way feat_dropdown does for model verbs, so the offer could name a family but only ever arm its first tool — Rectangle always gave a corner rectangle. Adds the registration, 14 atlas verbs (including the entire array family, which was absent, and rotate/scale), an action for the sk_move row that previously did nothing when picked, and a second submenu level so variants nest under their family instead of flattening 19 create tools. Built green and verified on the rig: Oblique rectangle arms oblique, not corner. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LyRwbuq6fjn3VV9U9UvhBM |
||
|
Tommaso BianchiandClaude Opus 5
|
fd1bc092d8 |
Design: slot Radius caption, keyboard offer, plane combo removal, mass props, docs
Mirror of snaporca ac85277bac..0e7cb3ec78 (six changes, applied as a patch to DesignPanel.cpp rather than copied, so this fork's 30 permitted divergent lines survive — parity re-checked afterwards: the five shared files are byte-identical, DesignCanvas.cpp and DesignPanel.cpp differ by exactly 16 and 30 lines). - The straight slot's inline field says Radius, which is what it sets. It stores the half-width and passed the typed number through unchanged, so 30 produced a 60 mm slot. - The offer opens from the keyboard (Menu, Shift+F10), anchored on the viewport rather than wherever the pointer happens to be. The card hint names the new route. - The sketch card's Plane combo is gone; the plane comes from the viewport. Also stops build_candidate collapsing a face plane to a base plane while editing. - Mass properties and the dead Edit row are wired into the offer; DesignOffer.hpp is regenerated from tool_atlas.json, verified by re-running the generator and diffing. - docs/rig_build_traps.md + scripts/rig-build.sh, which derives its fork identity from project() so it cannot be pointed at the other fork's image or volume. - docs/design_tab.md refreshed (44 commits stale) + a PR description, with this fork's own merge-base and diff shape rather than snaporca's. Built green in the deps container with the new script and verified on the rig: Menu and Shift+F10 both open the offer at the viewport centre with the pointer parked off-canvas, and the sketch card shows no Plane row. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LyRwbuq6fjn3VV9U9UvhBM |
||
|
Tommaso Bianchi
|
7114e316ea |
Design: the offer ships — right-click the geometry, get what applies to it
Row order is RATIFIED (charter 4.1, 2026-07-31) and this is the first working implementation of it: right-click in the Design viewport and a vertical list opens at the pointer with the eight families in their fixed order, the verbs that apply live, and the ones that do not disabled IN PLACE carrying their reason. THE MAP EXISTS ONCE. DesignOffer.hpp is GENERATED from docs/ux/tool_atlas.json by docs/ux/mockups/gen_offer_table.py — the same file the 113 mockups are drawn from. A drawing and the product therefore cannot drift apart, which is the only way row constancy survives contact with a codebase. Never hand-edit the header. NOTHING IS RE-IMPLEMENTED. Each row routes to the code that already runs that verb: "key:S+E" through m_keys_feature, "key:L" through m_keys_sketch, "fly:material#4" through the feature flyout's own action, "btn:colour" through the standalone button. The offer is a second door onto the same room, so the toolbar, the shortcuts and the menu cannot drift into three behaviours. The 8 verbs with kernel support but no GUI path show disabled, which is honest and matches section 10 of the charter. Right-click only fires the offer when the canvas is IDLE. Right-click already ends a polyline chain and finishes the move gizmo; taking those over would break two working interactions to add a third. Two things the running build corrected, both found by looking at screenshots: - THE REASON MUST BE TRUE FOR WHAT IS IN FRONT OF THE USER. Taking the first refusal in a family printed "Transform needs a body — add or import one first" on a document that HAS a body, because the real obstacle was that nothing was selected. Now the reason comes from a verb that accepts the current selection and fails only on document state; if no verb in the family accepts this selection at all, it says "select something first" or says nothing. A menu whose whole value is telling the truth cannot ship a lie. - Classification follows the level the pick cycle has REACHED, not the face the ray happened to hit, so the header cannot name a face while the whole body is lit. Sketching on the face you merely clicked is untouched — that path is sketch_plane_from_selection (snaporca-3a2). Verified on :11 end to end: nothing selected shows Sketch live with Shift+S and seven greyed rows each explaining itself; a selected solid shows Move directly with Shift+Y (one applicable verb, so no submenu and no extra click) and five families as submenus. Both forks compile and link. Fork parity re-checked after the port: DesignPanel.cpp 30 divergent lines, DesignCanvas.cpp 16, every other CAD file byte-identical — the invariant exactly. snaporca-96r. |
||
|
Tommaso Bianchi
|
00948cf767 |
docs: the offer is a vertical list, and it opens on every machine
Folds the form-factor decision into the charter. 4.1 is rewritten around Tommaso's proposal — left-click selects, right-click opens a vertical list of icon / name / shortcut — and the radial is demoted to a "Rejected" subsection rather than deleted, because it is a good idea that loses on evidence and somebody will propose it again. The evidence is recorded with it: mean fill of 3.45 of 8, only two live slots on a fresh document, sketch Create needing nine addresses on an eight-slot ring, names that do not fit around a circle in translation, and a 380px disc over the model on a 1366x768 screen. The invariant survives the change of geometry, which is the useful proof: same eight families, same fixed order, nothing re-sorted or compacted. It is now stated as ROW constancy, and the one substantive gain is that unavailable verbs are disabled IN PLACE carrying their own reason, in strings the product already ships. An empty ring slot was mute; a greyed row teaches. On a first-run document the offer stops being a mostly-blank control and becomes a map of what the product does and what you must do first — which is the section 2 audience in one picture. Opening it is now a table rather than an assumption, because "right-click" is not a universal gesture: two-button mouse right-clicks, trackpads two-finger tap, a one-button Mac LONG-PRESSES or Ctrl-clicks, touch and pen long-press, and the keyboard uses the Menu key or Shift+F10. The long-press is explicitly an ADDITIONAL route — 6.2 forbids press-and-hold as a sole path and that stands, so the rule now names its own exception and closes it — and it must show that it is charging, or a user who lets go early concludes the product is broken (L5). Consequently: 6.2's keyboard bullet describes opening and walking the offer by key rather than by compass direction; the gate gains question 13 (every new pointer gesture declares its keyboard equivalent and what a one-button Mac, a trackpad and a touch screen do) and question 12 now asks whether tool_atlas.json was updated and the atlas regenerated; section 10 points at the rendered atlas and says the outstanding thing is ratifying row order, not drawing the map. snaporca-96r. |
||
|
Tommaso Bianchi
|
c4990ee956 |
docs/ux: draw the offer as a vertical list too, and it wins
Tommaso was not sure about the ring and proposed a vertical list: left-click selects, right-click exposes icon / name / shortcut. Drawn, it is better, and the reasons are visible in the renders rather than arguable. THE DISABLED ROW CAN SPEAK. This is the one that decides it. A ring slot that does not apply is an empty circle: it says nothing, and on a fresh document six of the eight are empty. A list row that does not apply is greyed IN PLACE with its own name and its own reason — "Create a sketch, or pick a solid face, first", "Create a solid body to pattern first" — which are strings the product already ships and which tool_atlas.json already carries. The first-run picture stops being a mostly-empty ring and becomes a map of what the product does and what you must do first. For the audience section 2 puts first, that is the whole ballgame. THE OVERFLOW DISAPPEARS. Sketch Create needs nine addresses; a ring of eight pushed Polygon and Point behind a "More" slot. Nine rows is just nine rows. The one measured defect in the ring design is not a defect in this one. SHORTCUTS READ AS A COLUMN. Right-aligned in a list they stack into something the eye learns passively, which is exactly the graduation path 4.1 claims — and it is the mechanism by which the power user Tommaso describes stops opening the menu at all. Around a ring the same keys are eight loose chips. Also, unglamorously: long translated names fit, arrow keys and screen readers work natively where a radial needs special handling, and a 324px box costs the 1366x768 machine far less than a 380px disc over the model. What the ring keeps: equidistant targets and a future flick gesture. Since the brief is that power users live on the keyboard, that buys less than it looks. The invariant is untouched — same eight families, same fixed order, nothing re-sorted, nothing compacted. Only the geometry changed, which is the point: the map survived a change of form factor, so it was a real map. Both forms are now rendered side by side for the same states, and the atlas opens with the pairs. snaporca-96r. |
||
|
Tommaso Bianchi
|
eb2fc986a4 |
docs/ux: the offer atlas — every tool, every state, drawn
The charter fixed the slot-constancy invariant but carried one hand-written eight-cell table as an illustration, and nothing of the offer exists in the product. Before any GUI code, the group needs the map itself: what verbs there are, what each one needs before it can be offered, and what the ring actually looks like in every situation a user can put it in. tool_atlas.json is the source of truth and it was extracted from the code, not from memory: verbs, shortcuts and the exact refusal strings from DesignPanel's six feat_dropdown call sites and the sk_key table, kernel coverage checked against CadFeatureType, headless coverage against McpControl's dispatch, and the selection kinds taken from the callbacks DesignCanvas actually exposes. It carries each verb's preconditions, so "why is that slot empty" has an answer already written in the product's own words. The eventual C++ table generates from this file too — the map exists once. gen_offer_mockups.py renders it: 20 selection kinds x 2 document states = 40 primary rings, plus 73 sub-rings, plus comparison sheets. 113 states, none of them hand-drawn, because a human drawing 113 rings is exactly how an address quietly changes. Everything is framed at 1366x768, the charter's own reach target, so L11 is tested in the mockups before it is tested in code. Three things the drawing found that the prose had not: - MEAN FILL IS 3.45 OF 8. The empty-slot rule is cheap in argument and expensive on screen; on a fresh document exactly two slots are live. That picture is the anti-clutter thesis made literal and it is the strongest image in the set. - SUB-RINGS MUST ANCHOR ON THEIR PARENT. Fanning them from north put Extrude at N, which is Create's address in the primary map, so the second level contradicted the first. Anchored, an address is two consistent strokes: Add material is NE and its first verb is NE again. - ONE FAMILY OVERFLOWS, AND ONLY ONE. Sketch-mode Create needs nine addresses on an eight-slot ring. That is the ninth-position pressure the charter predicted, arriving on schedule and measured rather than argued: either Point moves family, or the tail goes to a third level, or the ring is not eight. Every model-mode family fits. The generator refuses to wrap a tenth verb onto a first — silent collision is the one outcome worse than an ugly ring — and reports the overflow instead. Also fixed while looking at renders: the selection pill sat on top of the north slot's shortcut chip and hid it, and the scrim at 0.55 swallowed the very face the ring had been opened on, which is 4.1 failing inside its own mockup. Fork-neutral: the generator and everything it emits name no product, so both forks carry byte-identical copies. snaporca-2is. |
||
|
Tommaso Bianchi
|
c3d286070e |
docs: the offer is a fixed address space, not a context menu
Tommaso's requirement, and it changes what the offer IS: a tool must sit in the
same physical position whatever you selected. Click a face, an edge or a text
and fillet is in fillet's place every time. Position becomes an address the hand
learns, and the eye stops being needed.
That kills the ordering rule this section had two commits ago. "Most-used first
for that kind of selection" is adaptive ordering, and adaptive ordering destroys
the one property that makes a spatial menu fast — worse, it destroys it exactly
for the user who has just started to learn the layout. Office 2000 shipped that
idea and withdrew it. So: NO adaptive ordering, ever, in any form.
The invariant, written to survive every future feature: every tool has exactly
one address; that address is identical in every selection type where the tool
appears; slots for inapplicable tools are left EMPTY rather than compacted; and
adding a tool never re-addresses an existing one. Empty slots are the price of
constancy and they are cheap — a compacted offer is denser and unlearnable, a
sparse one is memorised in a week. An empty slot also answers a question ("this
cannot be done to this thing") that a silently-inert tool does not.
Radial rather than a strip, reversing what I proposed last time and for a reason
that only appears once constancy is the requirement: a direction from the click
point is an absolute address that survives the offer opening anywhere on screen
and survives being clamped at a screen edge, while "third item down" does not.
Centre is a hole so the picked geometry stays visible, and it names what is
selected, so a mis-pick is caught before a verb is chosen.
Every slot carries its keyboard shortcut beside the icon and the word. This is
the graduation path and it is why power users never see a conflict: you reach
for the place, the place says "F", and one day your hand types F before the ring
finishes drawing. The offer is the mechanism by which a beginner stops needing
the offer — one interface at two speeds, no advanced mode in between.
Also here: a proposed eight-position compass map across face/edge/body/text
(create, add, remove, dress-up, repeat, transform, reference, modify) offered as
the group's first ratification, with families opening a secondary ring under the
same rule; arrow/numpad direction addressing so the spatial map works from the
keyboard; a gate question 12 that treats re-addressing an existing tool as a
breaking change to every user's muscle memory.
snaporca-2is.
|
||
|
Tommaso Bianchi
|
d7583f0a2d |
docs: the grammar becomes object-driven, and commit stops being invisible
Two changes to section 4, both from Tommaso. FIRST: the selection does not merely feed the tool, it DETERMINES WHICH TOOLS EXIST. Point at a planar face and the product offers the small set of things a planar face can become; point at an edge and it offers fillet, chamfer and the sketch tools that can reference it. Nothing else, because nothing else is possible. This is the largest single thing available to us for a first-time user, and the reason is worth writing down: a beginner's difficulty is not operating a tool, it is not knowing which tools apply to what they are looking at. Sixty icons answer a question they cannot yet ask; a face that offers its own five verbs teaches the product by being used. It also deletes a whole class of failure — a tool that silently does nothing because the selection was wrong becomes unreachable. The offer is an accelerator, not a toll gate: toolbar and single-letter shortcuts keep working unchanged and consume the same selection, so an expert never looks at the offer and a beginner never needs the toolbar. Both routes land in the same place, which is how one interface serves all three audiences. SECOND: "click empty space to commit" is withdrawn. It was an invisible gesture with a destructive meaning — nothing on screen said it, and a stray click committed a feature still being adjusted. Exactly what L5 forbids. A pending feature now carries a confirm/cancel puck attached to its own geometry, beside its handles, with Enter/Escape mirroring it; empty space reverts to the safe meaning, clear the selection. The puck is an object in the scene, not a dialog: the camera orbits, the values stay editable, nothing is blocked (L4 intact). Two cases the rule has to get right or it damages the inner loop: continuous tools (line, rectangle, circle) still commit each entity on its own gesture — a tick per line would be miserable — and Enter/Escape end the tool rather than confirm an entity. And ambiguity resolves toward keeping work: starting another operation with a valid feature pending commits it rather than discarding it, because undo reaches everything and the recoverable direction is the right default. Section 10 gains the two honest consequences: today a selection offers nothing (the largest single item of new work this charter asks for) and committing is still the invisible empty-space click. snaporca-2is. |
||
|
Tommaso Bianchi
|
610acfcd37 |
docs: reach is the first accessibility, and it gets a law
The charter had accessibility only in the assistive sense — keyboard, contrast, colour, targets — and said nothing about who can get through the door in the first place. That was the larger omission. The premise of an OSS CAD tool is that a kid on a school laptop, with no licence, no account, no fast machine and nobody to teach them, can open it and make a real thing; a tool that only the equipped can run reaches people who were already going to design something. So the fourteen-year-old is now the FIRST of three audiences, ahead of the maker and the mechanical designer, with an explicit rule that when audiences conflict the earlier one wins unless someone writes down why not. L11 states the floor: runs completely on a low-end laptop with integrated graphics at 1366x768, offline, no account, and no capability withheld behind a tier, a plugin or a cloud service. Section 6 splits into 6.1 reach and 6.2 the assistive floor: the reference machine, the small screen as the layout target rather than the stretch case, files that belong to the user, learnable with no documentation, plain language at the entry tier, and exploration that is never punished — undo reaches everything, nothing asks the user to be sure. Consequences elsewhere: the screen budget is set by the smallest screen we serve, not the reviewer's monitor; the PR gate gains a reach question; B6 joins the benchmark (the inner loop on the reference machine, offline, fresh install) and every task is measured there rather than on a workstation. The side-panel debt now fails L11 as well as L1 — on that screen the cards leave the model a strip. One role addition: the absent audience needs a seat. The kid cannot file an issue, so someone owns B5/B6 and the group watches real first-timers quarterly. Approachability is the one thing here that cannot be argued from principle. snaporca-2is. |
||
|
Tommaso Bianchi
|
76690f66e9 |
docs: the UX charter names only this fork's product
The doctrine is shared but the document is not: each fork's copy now speaks about its own product only, so it reads as that project's own charter rather than as a note about a sibling repository. This is a deliberate divergence — the two copies must NOT be reconciled by a parity sweep. The CAD sources stay byte-identical; only this doc branches. snaporca-2is. |
||
|
Tommaso Bianchi
|
8cc08845a8 |
docs: UX guidelines and charter for the Orca-CAD design group
The call with SoftFever settled that Orca-CAD is one of the branches to be implemented and that a design+dev group forms around it. A group without a written doctrine reviews by taste, and a CAD reviewed by taste becomes FreeCAD one locally-reasonable side panel at a time. So the doctrine is written first, as something a reviewer can FAIL a pull request against: ten laws each with its own test, the interaction grammar they compose into, the accessibility floor as a merge requirement, and a ten-question gate answered in every UI pull request. The position is Shapr3D's interaction economy, not its feature list — direct, gestural, almost no chrome, depth revealed by what you touch. Depth for mechanical designers arrives as progressive disclosure of tools that never move, in three tiers, non-modal, with assemblies and exploded views obeying the same point-then-act grammar as a beginner's extrude. The one thing neither Shapr3D nor FreeCAD has is that we live inside a slicer: plate, nozzle, material and build volume are known at design time, so print-domain failures are warnings on the geometry, not a report. Section 10 is an honest inventory: what already complies, and the six things that violate the laws today, none of them defended. The appendix keeps the anti-patterns we have already paid for, because each one is cheap to reintroduce. snaporca-2is. |
||
|
NoisyfoxandClaude
|
63044b7661 |
feat: Add layout debugging/inspecting tool (#14919)
* Add wxInspector dep * Initial intergration of wxInspector * docs: add wxInspector plugins design spec Design spec for two wxInspector plugins (DPIAware + CustomWidgets) that expose OrcaSlicer's custom control properties in the inspector property grid. Covers: DPIAware scale-factor properties, Button, CheckBox, TextInput, SwitchButton, ProgressBar, Label, and LabeledStaticBox. * docs: add wxInspector plugins implementation plan 6-task plan covering: source changes to existing widget headers, DPIAwarePlugin, CustomWidgetsPlugin, registration helper, MainFrame/CMake wiring, and build verification. * feat: add getters/setters for wxInspector plugin access Add minimal public accessors to DPIAware (set_scale_factor, set_prev_scale_factor, set_em_unit, force_rescale), Button (GetStyle, GetType, IsSelected), CheckBox (IsHalfChecked), TextInput (GetCornerRadius), and LabeledStaticBox (GetCornerRadius, GetBorderWidth, GetBorderColor, GetScale). * feat: add wxInspector plugin registration helper Add RegisterOrcaInspectorPlugins() inline function that creates and registers the DPIAwarePlugin and CustomWidgetsPlugin as static instances (matching wxInspector's built-in pattern). * feat: add DPIAware wxInspector plugin Exposes DPI scaling properties (scale_factor, prev_scale_factor, em_unit, normal_font, force_rescale) on DPIFrame and DPIDialog widgets. Uses dynamic_cast for detection and a template helper to capture the correct static type for lambda accessors. * feat: add OrcaCustomWidgets wxInspector plugin Exposes Orca-specific properties on 7 widget types: - Button: Style, Type, Selected - CheckBox: Half Checked - TextInput: Label, Text Value, Corner Radius - SwitchButton: Value - ProgressBar: Proportion, Show Number - Label: Is Hyperlink, Font Point Size - LabeledStaticBox: Corner Radius, Border Width, Border Color, Scale Each widget type uses dynamic_cast for safe detection. * feat: wire wxInspector plugins into MainFrame and build Call RegisterOrcaInspectorPlugins() in MainFrame constructor after SetupInspectorAccelerator(). Add all 5 plugin source files to SLIC3R_GUI_SOURCES in CMakeLists.txt. * fix: move plugin registration to GUI_App::on_init_inner Register plugins once in app init rather than in MainFrame constructor, which may be recreated during the application lifetime. * fix: include plugin headers in Registration.hpp for complete types Static locals require complete type. Include DPIAwarePlugin.hpp and CustomWidgetsPlugin.hpp instead of forward-declaring. Also remove unused include from MainFrame.cpp (registration moved to GUI_App). * fix: qualify DPIFrame/DPIDialog with Slic3r::GUI namespace * Make DPIDialog inspectable. For other dialogs, we will add them if necessary later. * docs: add spec for moving wxInspectable into DPIAware template Move wxInspector::wxInspectable base class from DPIDialog and MainFrame into the common DPIAware<P> template, making all DPIAware widgets automatically visible in the inspector tree. Co-Authored-By: Claude <noreply@anthropic.com> * docs: add implementation plan for moving wxInspectable into DPIAware Co-Authored-By: Claude <noreply@anthropic.com> * docs: update spec/plan — move SetupInspectorAccelerator into DPIAware too Co-Authored-By: Claude <noreply@anthropic.com> * refactor: move wxInspectable and SetupInspectorAccelerator into DPIAware DPIAware<P> now inherits wxInspector::wxInspectable and calls SetupInspectorAccelerator in its constructor, making all DPIAware widgets automatically appear in the inspector tree with the Ctrl+Shift+I shortcut. DPIDialog now uses 'using' to inherit the constructor. Remove redundant wxInspectable inheritance and SetupInspectorAccelerator calls from DPIDialog and MainFrame. Co-Authored-By: Claude <noreply@anthropic.com> * fix: use LB_HYPERLINK constant instead of magic number 0x0020 Co-Authored-By: Claude <noreply@anthropic.com> * Clean up * Fix Linux build * Don't build wxInspector sample * Use shallow clone * Try fix flatpak build * Attempt to fix build again * Fix build failure caused by https://github.com/wxWidgets/wxWidgets/commit/436c16135ec7ddf580f44624bf74c592aae43b66 * wxWidgets build only download required submodules * This should fix build on Windows on ARM * Enable PIC * Disable layout inspector by default for public release * Use wxInspector 1.0.0 release --------- Co-authored-by: Claude <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
e2b921745d |
Add user documentation for the Design tab
docs/design_tab_upstream_portability.md explains the subsystem to a maintainer; nothing explained it to a user. This is that: what the tab is, how to get a first solid out of it, every tool grouped the way the toolbar groups them, and the keyboard shortcuts read out of the source rather than remembered. The limitations section is deliberate. Rib needing a sketch with an explicit open line, Surface Loft and Surface Fill having no hands-on verification, mates composing transforms instead of solving simultaneously, move-face and replace-face being absent, and the two quarantined kernel tests are all things a user would otherwise discover by hitting them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 5
|
f347afd22e |
Document the CAD subsystem's real dependency weight
Maintainers will ask what the Design tab costs before they will look at the diff, so measure it rather than assert it. The headline correction: the OCCT delta is THREE toolkits, not two. The comment in deps/OCCT/OCCT.cmake claimed "TKFillet + TKOffset (3.77 MiB, Windows only)". Walking OCCT's own adm/MODULES and each toolkit's EXTERNLIB shows ModelingAlgorithms holds twelve toolkits, that eight of them are built either way because DataExchange (the STEP path upstream already ships) depends on them, and that the true delta is TKFeat, TKFillet, TKOffset and TKXMesh — of which TKXMesh is never produced. So three archives are built: 7.40, 5.38 and 4.42 MiB. TKFeat is the interesting one. Nothing in the Design tab references it and it is absent from the TKFillet/TKOffset dependency closure, so it is built for nothing — OCCT's module flag is all-or-nothing per module. On static-link platforms that is build time and zero shipped bytes. Two numbers are deliberately absent, marked as absent, and not approximated: the Windows DLL delta needs a Windows build (snaporca-gix), and a clean-build time delta needs the deps prefix built twice on one machine. The old 3.77 MiB figure is withdrawn rather than reused — it covered two of the three toolkits. Also recorded: the vendored solver is 9,339 lines under GPLv3 with its LICENSE preserved, which combines into this AGPLv3 fork without difficulty (AGPLv3 §13), and it is live code driving every sketch constraint — not a carried corpse. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Tommaso BianchiandClaude Opus 4.8
|
52a8ca965c |
docs: capability gap analysis of the Design tab against Onshape
Enumerated from the source rather than from recollection: CadFeatureType and add_* in CadDocument.hpp, Tool in DesignPanel.hpp, Mode in DesignSketchTool.hpp, SketchConstraintType + SketchEntity::Type in SketchEngine.hpp, and the JSON-RPC dispatch in McpControl.cpp. Findings worth stating up front: - The 2D sketcher is at or near Onshape parity -- 19 constraints, every entity type including B-splines and elliptical arcs, trim/extend/offset/mirror and both array kinds. Very little is missing there. - The gaps are all breadth beyond sketching: assemblies/mates, surface modelling, sheet metal, drawings, and variables/configurations. - The most defensible criticism is the absence of variables and expressions. Every dimension is a literal double, so the feature tree is parametric in structure but not in value -- "change one number and the model updates" is only half delivered. It is also the cheapest Tier 1 item to close. The doc separates platform capabilities (version control, FeatureScript, FEA, rendering, cloud PDM) into their own tier rather than counting them as missing tools: that is Onshape-the-platform, not Onshape-the-modeller, and holding a slicer tab to it would not be a fair comparison. One entry is a correctness gap rather than a missing feature: move/rotate body (m_body_xform) is display-only and never enters the B-rep, so a moved body exports and booleans at its original position while the viewport shows it moved. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BVzKmX6Y1aEteit1HTXG4Q |
||
|
Tommaso BianchiandClaude Opus 4.8
|
8aea63a919 |
docs: rewrite the upstream brief from measurement, correcting two errors
The 2026-06-21 assessment was written before the persistence work landed and got two load-bearing facts wrong. Both are corrected here against the branch itself rather than from recollection: 1. It called OCCT "a dependency mainline OrcaSlicer has never carried" and built its whole conclusion on that. False: deps/OCCT/ exists at the merge-base, and upstream already links it from Format/STEP.cpp, Format/svg.cpp and Shape/TextShape.cpp. The real dependency diff is one line -- BUILD_MODULE_ModelingAlgorithms OFF -> ON -- costing a measured 3.77 MiB of Windows DLLs (TKFillet + TKOffset; TKBool already arrives transitively via DataExchange). 2. It described the vendored SolveSpace solver as LGPL. False: src/libslic3r/slvs/LICENSE is GPL-3.0. Harmless for us, but a licence must not be misstated in a document aimed at upstream. It also claimed no changes to Model, which stopped being true when 3MF recipe persistence added a std::string there. The rewrite replaces prose estimates with counted figures: 138 new files, 23 modified upstream files at +457/-75, nothing deleted, 99.3 % of the diff in new files. That reframes the ask from "adopt a CAD kernel" to "widen a build flag you already carry", which is the argument that actually has a chance upstream. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BVzKmX6Y1aEteit1HTXG4Q |
||
|
Tommaso BianchiandClaude Opus 4.8
|
0f4060c0a9 |
Orca-Cad: port SnapOrca Design (parametric CAD tab) onto mainline OrcaSlicer
Grafts the sketch-first CAD environment from snaporca-cad onto the mainline OrcaSlicer/OrcaSlicer base (vs snaporca's Snapmaker/OrcaSlicer base): - 133 new files: CadDocument/SketchEngine/GeometryEngine/SketchConstraints/ SketchSolver/SketchInference/ThreadStandards + vendored libslvs solver; DesignPanel/DesignCanvas/DesignSketchTool/SketchInlineEditor GUI; GLGizmo Primitive/Sketch; 75 design icons; Catch2 tests. - Integration hooks ported to mainline's diverged versions: Design tab in MainFrame, embedded design viewport + sketch overlay + per-canvas chrome suppression in GLCanvas3D/PartPlate, gizmo registration, Plater accessors, CMake wiring (libslvs subdir, CAD sources, OCCT ModelingAlgorithms=ON). Structural integration complete; build verification pending. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BVzKmX6Y1aEteit1HTXG4Q |