* claim: #4071
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Define a named parameter inline from any value input (#4071)
Any value input, typed or sent as a command's expression parameter, takes
`name = expression` (or `#name = expression`): the design gets the user
parameter `name` with that expression, and the input stores `name`, in the
command's one undo step.
- doc: the lexer skips a definition's `name =`, so until the design stores
it the text evaluates as its expression and commands read and check it
like any value. `Document::define_inline` then turns every stored
definition (feature inputs and placements, dimension parameters, sketch
pattern and text values, joint and coupling values, sheet metal and
plastic rules, canvas planes) into a user parameter, the unit following
how the input reads a bare number. A taken, reserved or empty name, two
different values for one name, and a definition in a parameter's own
expression or a configuration cell are refused; all or nothing.
- engine: `Session::execute` runs it after any command whose parameters
hold definition-shaped text; the reply has `defined` (the first name,
as `sketch.dimension` already gives) and `definitions`. A refusal fails
the command, which leaves the design as it was.
- `parameters.change` with `new = expression` renames the parameter it
changes (a dimension's or feature input's own, references following)
and sets it; when the value is just `new`, it sets `new`. `changes`
refuses definitions. `expr.evaluate` reports `defines`.
- UI: lengths keep the name when the design unit is applied; sketch text
sends a definition as typed and previews only its value; the box corner
and offset Distance 2 use the value; fields whose command keeps no
expression (sketch scale, move, chamfer) refuse a definition with the
way to name it. The dimension editor says which parameter it named.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* claim: #6901
* Feature windows choose Join, New Body or Cut from what the material touches (#6901)
Extrude, Revolve, Loft, Sweep, Coil and the Box, Cylinder, Sphere and Torus choose
their operation by running the Join on a copy of the design off the window thread
and counting the pieces: Join when the material makes one body with what it
touches, New Body when it would be a separate piece, Cut when it lies inside a
body (Revolve and the four primitives; Extrude keeps its own Cut). The choice
changes only when a check is in, a pick in the Operation row (the shown option
included) stops it for good, and OK waits for a running check. Hidden bodies take
no part: with some hidden, the shown ones become the feature's targets.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Operation row: a pick in Extrude stops its own choice at once; ja/zh strings, gallery entry
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Operation check: contact test first, mesh volumes for Cut, OK takes the evaluated Join
Material touching no body is a New Body without running the Join (the contact
test costs 0-240 ms where the Join costs seconds on a large body). Inside is told
from display-mesh volumes instead of exact ones (8 s on a 400-hole plate). The
check evaluates the Join through Session::ahead, and OK of the same commands
takes it (Session::prime) rather than computing it again.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Preference: Choose the operation automatically (on by default)
Preferences > Design gets "Choose the operation automatically" (auto_operation,
on by default). Off, feature windows don't choose Join, New Body or Cut from
what their material touches: each keeps the operation it opens with (Extrude
its own Join or Cut), no check runs and OK doesn't wait for one, as before
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Arabic, Hebrew, Vietnamese and Turkish strings for the operation choice and its preference
Arabic, Hebrew and Vietnamese are complete catalogs now, and Turkish has a full
catalog, so this change's three strings get them too.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Operation check: a closed window's check stops; the icon audit doesn't choose
A window's operation check kept running after the window closed, a Join on
the design for nothing, and the test harness waited for it after every step:
the icon audit, which opens every window, took ~30 min instead of ~1. The
check now runs under a Progress, and closing the window (or one that doesn't
choose) abandons it: its evaluation stops at the next feature and nothing
waits for it. The icon audit turns auto_operation off, as it only looks at
icons (75 s again).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Box placement test: the window keeps its New Body
The test #6248 added places a box that overlaps Base and expects a second body;
with #6901 the window would join or cut it. The test is about where the box
goes, so it turns auto_operation off.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Join pieces: read the target lists leniently after the rebase
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: bherbruck <brennen.herbruck@gmail.com>
* claim: #7717
* Stand-up offer: a note only when the part seems to lie on its back (#7717)
* Stand-up note: an unclear shape still gets the note
* Stand-up note: a Don't ask again button, as the dialog has
* Control protocol: the stand-up settings in the sorted ui.prefs list (#7717)
* Stand-up note: the control import test asks as before (#7717)
The test checks the caller's `up`, so it sets the setting to Ask and every
file from another program still gets the offer.
* claim: #4086
* Raise the largest file SolidCraft opens with a setting or launch flag (#4086)
* Translate the file size limit strings
* Size limits: design files are .sc now, .solidcraft still read
* Sketch: show center and midpoint alignment guides
Add transient per-viewport horizontal and vertical guides with a sketch preference. Related tests, native UI, WASM and supplementary Linux checks pass. Full CI remains blocked by unchanged Windows engine dead-code Clippy errors.
* Sketch: complete alignment-guide translations
* Tests: compile chosen-program mutex only on Unix
* Links: update linked designs that changed while the assembly's tab was away
A design coming back to its tab compares the modification time and size of its linked
design files with what they were when it went to the background, and runs Update Links
on the worker thread for those that changed: saved in another tab, another window or by
a checkout. Preference update_changed_links (Design, Linked designs) turns it off.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Docs: the assembly guide says linked designs update when their tab returns
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Links: Vietnamese strings, now that vi is a complete catalog
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Links: remember what each design last read, so an update that fails is tried again
A design's linked files are now recorded as the design last read them: when Update Links reads a
link without an error, or when the link is first seen. Coming back to the tab reads again what
differs, one link per run, so a file that cannot be read holds up no other and is tried again
the next time, and a part changed while the assembly was shown is taken up on its next return.
Closing several tabs together reads nothing on the way, and the web build, which keeps no file
times, looks at nothing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Links: no read during a save-changes prompt, records for adopted designs and missing files
A tab shown to answer "save changes?" reads no link before its save, and Cancel there or on a
batch lets the tab left in front read what it skipped. A design opened in place of the blank one
records its links at once, a link whose file is missing is recorded as missing so it is read when
the file comes back, and a read queued for a design that is no longer shown by the time it starts
is dropped. More changed links than can wait at once are read on the next return.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Assemblies: edit a linked component in place, with the assembly around it
Activating a linked component opens the design it comes from in a tab of its own, with the
rest of the assembly drawn faded around it where the component sits, so the part's own history,
browser and commands are at hand. Finish Editing in the browser saves the part, goes back to the
assembly and closes the part's tab when the edit opened it; coming back to the assembly updates
the changed link (or Finish Editing runs Update Links when that is turned off). Update Links in
the part also reads the assembly's links again, off the window thread, and redraws the assembly
around the part; a result for an assembly changed meanwhile is dropped with a message.
The part is an ordinary tab, so saving, autosave, recovery, closing and quitting treat it as any
other design. The model scene's ghost triangles are now drawn (only the preview's were).
Preference edit_linked_in_place turns it off. Builds on the update of changed links when an
assembly's tab returns.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Edit in place: a double-click opens it, Activate only activates
A double-click on a linked component edits it in place, in the browser as on a face in the
view (around the placement clicked), and the component's menu gets Edit in Place. Activate and
the browser's radio button make it the active component as they always did, so a linked
component can still be activated without opening its design.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Double-click on a component's face: edit a linked one in place, activate any other
A double-click on a face in the view activates the component the body belongs to, at that
placement, as a double-click on its row does; a linked one is edited in place. Bodies of the
design itself or of the active component are left alone, and so is a double-click with a
modifier. One preference, double_click_components, covers both gestures.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Edit in place: fixes from review
An edit whose part never opens is forgotten instead of starting on a later open of the same
file, and the web build starts the edit after its synchronous open. Finish Editing goes on only
for a save into the linked file and in the part's own tab, waits for a "changed on disk"
answer, and says so when the part was saved elsewhere. Showing the assembly no longer drops a
refresh, which now records the links it read so coming back reads nothing twice. The faded
assembly is worked out once per picture, a bad mesh index skips its whole triangle, and the
last two status texts come from the catalogs.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Edit in place: Finish Editing on the MODEL tab and the mouse's back button
Finish Editing is a command now, component.finish_edit, with its schemas: the app window
answers it, anywhere else nothing changes, as with view.fit. While a linked design is edited in
place the MODEL tab ends with a FINISH EDITING panel, pinned at the right as FINISH SKETCH is,
with a new left-arrow icon; the browser keeps only the line naming the assembly. The mouse's
back button, or a keyboard's Back key, finishes too unless a dialog, tool or sketch is open.
The assembly guide describes editing in place.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Edit in place: fixes from the second review
Saving the assembly waits while it reads its links for the part
Finish Editing waits for dialogs, tools, sketches and prompts open in the part, also when run as a command
The assembly reads the edited part explicitly when it does not check its links on its own
The FINISH EDITING panel cannot be customized
A tab opened by an edit stays that edit's to close when the part is entered again
The mouse's back button finishes editing; the keyboard's only while no text field has focus
Refreshing the assembly keeps its selection and active component
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Edit in place: fixes from the third review
component.finish_edit run as a command opens nothing and answers with an error when it cannot finish; engine.batch and engine.script refuse it
A double-click or Edit in Place while a dialog, tool or sketch is open in the assembly keeps it open
What changes in the assembly while it reads its links without changing its document stays: picks, activation, components dragged but not captured
Showing the assembly while it reads its links starts no second read
A new or opened design in the part's tab ends the edit
Finish Editing keeps the part's tab open while its agent chat runs
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Edit in place: Update Links run as a command in the part refreshes the assembly too
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Edit in place: the ribbon button reads Finish Edit, as Finish Sketch does
A bare "Finish" took the catalogs' surface-finish translation (German "Oberfläche").
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Edit in place: fixes from the fourth review
Finish Edit waits while the part's agent is in the middle of its turn, instead of keeping the tab of any chat open
A part saved while its assembly refreshes is read again when the edit finishes: the refresh records the files as it found them
A double-click on a linked component while something is open in the assembly says so instead of activating it
Commands are recognised in any spelling the engine takes, so engine.batch and engine.script cannot slip Finish Edit through
Update Links run as a command refreshes the assembly from the control channel only, not for the app's own reads
Moves of components the refresh removed are not carried over, and a refusal is one message
The command description and the guide say that the command does not save the part
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Edit in place: the command is Finish Edit, as Finish Sketch is
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Edit in place: a command to start it, and fixes from the full review
Added component.edit_in_place {component, path?}: the double-click and Edit in Place in the menu run it, and as a command it asks nothing, so a network location not allowed yet or a design open elsewhere makes it fail instead
Finish Edit asked by the part's own agent finishes once that agent's turn ends; the button still waits for the turn
The parameters and design properties panels, with text typed and not applied yet, hold up entering and finishing an edit
A refresh is not taken up under an undo, a queued command or a feature still being computed in the assembly
Refusals say what holds them up (a refresh, a file being read or written) instead of nothing
The browser strip names the assembly that is refreshing, not any assembly
The schema description says the command does not save the part
Korean strings for every new message
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Edit in place: fixes from the second full review
The MCP batch tool refuses component.edit_in_place and component.finish_edit as steps instead of sending them one by one
Edit in Place asked while the assembly's agent is in its turn opens the part once the turn ends; a double-click then is refused rather than stopping the agent
Both commands answer queued: true when they wait for the agent's turn, and stopping the agent forgets what it queued
An undo, a queued command or a delete check running in the design holds up entering and finishing an edit
A refresh redraws every edit of the assembly, the parts in other tabs too
In an assembly never saved, a double-click activates the linked component as before
The control and MCP docs list the new batch and script refusals, and the commands list every way they fail
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Edit in place: fixes from the third full review
The MCP batch tool refuses the two commands however a step names them, an execute step too
A queued Edit in Place is checked fully when asked for, a second one is refused, and both queued requests wait for what runs in the design instead of being dropped
Disconnecting the agent forgets what it queued, as stopping it does
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Edit in place: help text for the Finish Edit button
main now requires help for every toolbar command (#7134), and Finish Edit
is one. Written in every language the branch's catalog carries.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Logo: an option to draw it in the theme's accent
Preferences > Interface > Logo: Theme's colours (the default, as before) or
Accent, three shades of the theme's accent. ui.prefs logo_accent.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Logo: US spelling for the option's label, as upstream's English catalog uses
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Translations for the new options in the five complete catalogs (ar, he, ja, vi, zh)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* claim: #5240
* Preferences: reverse vertical pan direction (#5240)
Add "Reverse vertical pan direction" beside the horizontal setting in
Preferences > Navigation. pan_reverse_y defaults off, so older settings
files load unchanged, and flips the vertical part of two-finger pan on
every canvas through navigation::handle, independent of the horizontal
setting. Labels in en, ja, zh, de, and ko.
* Reverse vertical pan: strings as a pending locale file, with Arabic, Hebrew and Vietnamese
* Control protocol: pan_reverse_y in the sorted ui.prefs list (#5240)
* claim: #7181
* MCP save: a folder the agent opened or saved a design in stays in scope (#7181)
The agent's default folders held the open design's folder only while that
design stayed open there, so after a new design, an opened STEP file or a
save-as elsewhere a save beside the earlier design was refused, while the
same save through the control port worked.
The MCP server now keeps, for the rest of its run, the folder of every
design file a call opened or saved (open, save, and doc.open, file.save,
file.save_as through execute or batch, path given in full) and, headless,
of every design open in its session. Such a call only succeeded because the
folder was already in scope, so naming a path adds nothing. The folders get
the open design folder's terms (inside home or temp, not hidden, hidden
entries unreachable), at most 16. Bridged, they go to the app as
design_folders, which it judges the same way.
The save tool description and docs/mcp.md say how to add a folder with
--allow-path.
* MCP scope: a design's folder is the folder its file resolves to (#7181)
A link in another folder to a design inside the agent's folders passes the
scope check, which follows it, but its own folder was what got remembered
(and, for the open design, what counted while it was open). Take the folder
of the file as the check resolves it.
* Control test: a hidden file the export format accepts (#7181)
---------
Co-authored-by: MateuszSychXpl <151755914+MateuszSychXpl@users.noreply.github.com>
* claim: #4217
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Browser: Bodies folders only where they help: Always, Several bodies only (the default) or Never (#4217)
A new preference on the Interface page, in the Layout section under Browser, sets when a
component's bodies sit in a Bodies folder of their own. Several bodies only lists a component's
lone body, when it has no groups, straight under its placement. Never lists every component's
bodies and groups there. Always keeps the folder as before. The design's own Bodies folder and a
folder hidden with its eye always stay.
One rule, browser::bodies_folded, decides it for the rows and for the menu. A folded folder
draws no row and stays open; its items move up one level, and their own eyes, hover and drops do
its jobs. While a folder is folded, its placement's menu takes the folder's Create Components from
Bodies and Group Selected; New Group and Show All were already there.
ui.prefs takes browser_bodies_folders (always, several, never) and refuses other values; saved
preferences read an unknown value as the default. The s37 scenario sets Always so that it still
checks the Bodies folder's chevron.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Browser: Bodies folders in Arabic, Hebrew and Vietnamese too (#4217)
Arabic, Hebrew, Japanese, Vietnamese and Chinese are complete catalogues, so
every_complete_catalog_carries_every_english_message fails a new message any of them lacks. The
preference's four messages get their Arabic, Hebrew and Vietnamese text, in the words those
catalogues already use for a body and a folder.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* claim: #7371
* Browser with History under it: drag the split between the two cards (#7371)
Under the browser, History took exactly half the column. The seam
between the two expanded cards is now a grip with the vertical resize
cursor; dragging it moves the split, as the column's right edge moves
its width. The split is kept as the browser's share of the column in
a new preference, browser_share, whose default is the equal split, so
nothing changes until someone drags.
Either card keeps at least its header and two rows. Folding either card
works as before and gives the other the rest; while one is folded or
folding there is no grip. A non-finite share falls back to one half.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FN5eEMrqWWXqi65FcK8GXq
* Prefs: keep the browser share with the History-under-browser settings
Moves the entry so it no longer sits next to the render and dialog
preferences that main added after browser_width.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: sascha2101 <221609842+sascha2101@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* claim: #6707
* feat(dialogs): open in the left column in place of the browser and History (#6707)
* fix(i18n): Vietnamese messages for the dialog placement option (#6707)
* claim: #7009
* Assistant: connect the last-used agent and open the panel at start (#7009)
Two Settings > AI options, off by default: when SolidCraft starts, connect
the agent started last (once the installed agents are known; a missing one
is not swapped for another) and open the Assistant panel. Not for runs
started with --control.
A connection that never gets ready (no agent, start error, the agent ends
while starting) is a new Failed state: the header reads Connection failed
and Connect reads Retry. The control channel reports it as "failed" and
takes connect_at_start / open_at_start.
* Assistant: keep the start-up agent when a design replaces the blank one (#7009)
Opening a design over the blank design SolidCraft starts with reset its
chat and stopped the agent connected at start. A chat not asked anything
yet now starts over in place and keeps its agent. Turning AI features
off also drops a start-up connection still waiting for discovery.
* i18n: Arabic, Hebrew and Vietnamese for the start-up options (#7009)
ar, he and vi are complete catalogs on main now, so every new English
message needs them.
---------
Co-authored-by: MateuszSychXpl <151755914+MateuszSychXpl@users.noreply.github.com>
* claim: #6981
* Drive Joints: say why a rigid joint can't be driven and offer Edit Joint (#6981)
Drive Joints opened on joint 0 when no joint moved, and its preview ran
joint.drive on that rigid joint, so the dialog showed a red "a rigid joint
does not move" with a Create Issue button.
The dialog now says a rigid joint holds its parts still and how to let them
move (Revolute to rotate, Slider to slide, Cylindrical for both), with an
Edit Joint button that turns it into Edit Joint on that joint. Its commands
refuse a rigid joint, so nothing is previewed and OK stays off. A rigid
joint picked in the browser opens Drive Joints on it to say the same; the
joint box lists only joints that move. joint.drive's own refusal names the
types that move and joint.edit.
* Drive Joints: the rigid joint message in Arabic, Hebrew and Vietnamese (#6981)
Main now delivers ar, he and vi complete, so every new message needs them.
---------
Co-authored-by: MateuszSychXpl <151755914+MateuszSychXpl@users.noreply.github.com>
* claim: #3457
* Hebrew interface language with right-to-left text (#3457)
Adds a complete Hebrew catalog (assets/locales/he.json, original
translations) and registers `he`.
egui 0.36 shapes each font run with harfrust, so a run of Hebrew letters
is drawn right to left, but it places the runs of a line left to right in
stored order. The new `bidi` module runs the Unicode Bidirectional
Algorithm (unicode-bidi, MIT OR Apache-2.0) over each message of a
right-to-left catalog once, giving egui the runs in display order with
brackets mirrored and placeholders kept whole, while leaving each Hebrew
run's letters in reading order for the shaper. A test lays messages out
with a real Hebrew font and checks where the glyphs land.
Desktop builds append a system Hebrew font (Arial Hebrew / SF Hebrew,
Segoe UI / Arial, Noto Sans Hebrew / DejaVu Sans). Layout mirroring,
wrapped multi-line RTL paragraphs and a web Hebrew font are follow-ups.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Hebrew: translate the new Describe Command label; list he in the control protocol
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Hebrew: catch up with main's catalog and the new ribbon (#3457)
- Translate the 258 messages main added since the branch was cut, drop
the 38 it removed (10 renamed ones keep their translation) and
retranslate the two whose English changed (toolbar → application bar).
- The timeline title is ציר הזמן, matching the glossary.
- Ribbon buttons split their labels into two lines from the start of
the string; Hebrew labels come in display order, so the first line
showed the end of the phrase ("חדשה / סקיצה"). For right-to-left
labels the first line now takes the words at the end of the string,
and a shortened line loses characters, and shows its ellipsis, on the
left. The word-boundary sweep checks Hebrew from the lines the galley
is built from, since epaint's right-to-left rows carry zero-width
glyphs.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Hebrew: after rebasing onto main, load the Hebrew face with the cached system fonts
main now searches the system fallback faces once (SystemFonts, on a thread);
the Hebrew face joins that search with its coverage check. Drop the three
camera-animation messages main removed (#4296) from the Hebrew catalog.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Hebrew: translate the messages main added after the catch-up (#3457)
Translates the messages main added since the last catch-up: the history
bar's buttons and name toggles, the 3D mouse driver and axis mapping, the
thread size columns, the File view (home page), the redesigned Preferences, the new issue report
dialog, free orbit and the assistant's setup card. Drops the one message
main removed. The catalog has every English message again, so the
complete-catalog checks pass for he.
* Arabic interface language (right-to-left, on the Hebrew bidi path)
Adds an original Arabic translation of the whole English catalog
(assets/locales/ar.json, every message) and registers it. `ar` joins the
complete catalogs, so a message added to en.json later fails the build
until it is translated. It goes through the right-to-left path of #3458
unchanged: crate::bidi puts each message in display order and leaves
every Arabic word's letters in reading order for harfrust, which joins
them with the font's own tables. Ribbon labels use the right-to-left line
split from the same stack.
fonts.rs adds a system Arabic fallback after the Latin interface font,
which keeps spaces, digits and Latin text so each Arabic word stays one
shaped run: Segoe UI/Tahoma/Arial on Windows, SF Arabic/Geeza Pro/
Damascus/Tahoma on macOS, Noto Sans or Naskh Arabic/KACST One/DejaVu Sans
on Linux, or NotoSansArabic-Regular.ttf in CRAFT_FONTS_DIR. It is the first
fallback for an Arabic UI (Arial Unicode, a CJK candidate, has Arabic
letters without joining data) and the last otherwise; like Thai and
Hebrew it is never promoted for a CJK interface.
Tests: the catalog comes back in display order with no directional
controls, and Arabic laid out with a real font lands on screen word by word
in reading order.
* Hebrew: review the catch-up translations; restore the camera-animation messages (#3457)
- Review of the 533 messages translated in the previous commit: 21
corrected. Keys in the motion dialog are keyframes (נקודות מפתח, as
in Add Key), the Design workspace is תכן as in its label, a dropped
"(Direct Driver)" is restored, terms aligned with the rest of the
catalog (פורמט, סוכן קוד, רצועת הכלים), and a few calques reworded.
- Translate ui.animate_view_changes, ui.animation_speed and
ui.look_at_anim_desc, which main has again, so he stays complete.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Arabic and Hebrew: translate the messages main added since (#3457, #3762)
Both catalogs again carry every English message. The 760 messages main added
since the last rebase (render workspace, material editor, standard views,
sheet metal Path Flange, AI app connections, document-on-disk notices and
more) come from A-AL-ANAZI's translations on #3768; the five Perforate dialog
messages are new here. The earlier Hebrew review is kept on top of them, and
33 of the new Hebrew messages are corrected: "completed" was "perfect"
(מושלם → גמור), Regrade read as ranking (now תיקון צבע מחדש), shaders,
guarantee, the Mirror reflection mode, simulations and displacement.
Co-authored-by: Abdullah <alksa2025@gmail.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Arabic and Hebrew: attribution rows as a pending file
main now takes new ATTRIBUTION.md rows as one file per change
(attribution/pending/), so the he.json and ar.json rows move there.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Arabic and Hebrew: translate the 23 messages main added since (#3457, #3762)
Both catalogs again carry every English message; the two theme-page messages
main removed are dropped. Twelve of the new messages (link updates while
loading, the agent chat's model choice, plugin search, render quality) come
from A-AL-ANAZI's translations on #3768; the sketch plane descriptions, the
rigid group and empty-boolean messages, free sketch points and the web update
note are new here.
Co-authored-by: Abdullah <alksa2025@gmail.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Arabic and Hebrew: translate the 12 messages main added since (#3457, #3762)
Eleven come from A-AL-ANAZI's #3768; "Turn Up Axis" in Hebrew follows the
catalog's existing up-axis wording, and the agent chat's no-tool-call message
is new in both.
Co-authored-by: Abdullah <alksa2025@gmail.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Arabic and Hebrew: translate the 22 messages main added since (#3457, #3762)
* Arabic and Hebrew: a label found by its English text comes back in display order too (#3457, #3762)
* Arabic and Hebrew: translate the 32 messages main added since (#3457, #3762)
* Arabic and Hebrew: translate the 34 messages main added since (#3457, #3762)
* Arabic and Hebrew: translate the 30 messages main added since (#3457, #3762)
* Arabic and Hebrew: translate the 7 messages main added since (#3457, #3762)
---------
Co-authored-by: rootarchitect <7781866+rootarchitect@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Abdullah alanazi <x1700@MacBook-Air-Abdullah-2.local>
A homemade 3D input device's driver app (MAKMOUSE) listens on a loopback
port; with Preferences > Navigation > "Navigate with a device app on this
computer" on (off by default), the desktop app connects, says hello and
reads JSON lines: axis motion (orbit, pan or zoom by mode), zoom steps and
standard views. The motion goes through navigation::device like a 3D
mouse's, only in the focused window; a HID device the app names is left
to it. Documented in docs/3d-mouse.md.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Double-click a shown sketch dimension in the model view to edit its value (#7079)
A finished sketch's dimensions shown in the model view (Show Dimension) now take a
double-click: the same inline value box as sketch editing opens at the text, Enter
changes the dimension's own expression through parameters.change (one undo step), Esc
cancels. The sketch is not edited and the view does not move. Driven dimensions stay
read-only with a status hint.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Control channel: ui.selection lists the shown dimensions of finished sketches
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Test: a shown dimension that breaks a later fillet reports it, and Undo restores both
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* claim: #4384
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* Placement handles: shared module, with Rest as the first tool
The Rest handles spike becomes a shared module, place_gizmo, so other features placed on a face can
use the same marker and knob. The mechanics (crosshair with its three states, the grab offset, the
footprint while dragging, the turn knob) live in place_gizmo.rs. The handles own the pointer through
canvas::owns_pointer, as the move triad does, so navigation and Select Other's press-and-hold leave
them alone. Each tool is one file under place_gizmo/ that gives a Spec: which dialogs it serves,
which commands' Position input also takes sketch points, where the place is, how the pointer
re-places it, its footprint and its turn, if any. The module lists the tools one per line, so tools
added on separate branches each add one `mod` line and one list line. Rest is the first.
The handles are always on; the preference the Rest spike had is gone. The POINTS accept flag on a
Position input is granted from the tools' Specs instead of a Rest-only arm in the plastic dialog's
start. Handles are published as `rest:position` and `rest:rotate` as before.
Seen straight down, the dialog's height arrow collapses onto the place and its value box sits just
right of it, where it took the press meant for a knob pointing that way. The knob now slides out
along its ray until it is clear of the box.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Placement handles: Boss
The marker moves a boss across the model, also from Edit Feature, and its Position input takes
sketch points while the handles are on, so a screw boss can be dragged onto the centre of a
circle drawn for it. A boss is round, so it gets no knob; the footprint while dragging is its
outer circle. Published as `boss:position`.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Placement handles: Snap Fit
The marker moves a snap fit across the model and its Position input takes sketch points while
the handles are on, so the arm can be put where a sketch says (#3423). The knob points the
catch: it turns between the four directions the Catch Direction combo offers for the face, so
the knob and the combo always agree; the command keeps only those four, so there is no free
turn. The footprint while dragging is the arm's foot, its thickness behind the place and its
width across. Published as `snap_fit:position` and `snap_fit:rotate`.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Placement handles: the look in one file
Everything that draws the handles (the crosshair and its three eased states, the knob's ball, the
cased lines, the angle label, the colours) moves from place_gizmo.rs into place_gizmo/look.rs, so a
restyle touches one file and the mechanics (hit radius, drags, knob geometry) stay where they are.
No change in behaviour.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* Placement handles: behind a Design preference, off by default
The handles sit behind Preferences > Design > Placement > Placement handles (`placement_handles`,
also through `ui.prefs`), off by default as the hole placement work in #2912 is: a Rest, Boss or
Snap Fit is then placed by its click alone, its Position input takes faces only, and no handle is
drawn or published. The tests switch the preference on; one checks the default.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* Placement handles: the tests hide the origin through set_origin_shown, as main does since #1849
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* Placement handles: the move marker as designed in the prototype, drawn with theme tokens
The marker is a dot with four arms to the screen cardinals: short and dotted at rest, longer with open arrowheads when pointed at, solid while dragging, each state growing out of the previous one (360 ms). Sizes are the prototype's. Its core is the icon highlight and its casing the marker halo, the tokens main's hole handle uses, so the literal allowance goes. The tip shows while pointing, not during a drag.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* Placement handles: the dialog's drag arrow stands above the move marker
With the handles on, the Height arrow started at the marker's centre and ran through its upper arm, head on arm tip. The arrow now keeps the marker's full reach and a gap free at the base, its shortest length grows by as much, and the base dot is left to the marker. Other dialogs are unchanged (clearance zero).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* Placement handles: a turn ring on the face replaces the knob
The ring lies on the face about the move marker's centre, drawn in perspective, a fixed 65 px on screen like the move triad's arrows (it is a control of something on the screen, not a measure of the model). At rest it is a short dotted arc with an open chevron grip just outside; pointed at, the dotted circle opens from the grip both ways round and the grip slides in and fills; while turning, a solid arc around the grip. Dragging the grip turns the feature as the knob did, through the same handle name, so the harness tests stand.
The floating value box yields: with a handle's centre under it, it moves to the other side of the arrow's tip or above it, since seen straight down the box sat exactly where the grip is. A handle the arrow's stem crosses keeps the pointer.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* Placement handles: a compass while turning, and the turn pulled onto the face's compass points
Four ticks just outside the ring at the face's in-face world directions (the ones the Snap Fit combo names, +X, −Y, …) appear while turning and stay put, so you can see how far you have gone. A Rest's turn is pulled onto one of them within 8°, otherwise it steps by 5° as before; Alt or Ctrl frees it. The readout beside the grip names the point it sits on ("90° · +X") and keeps clear of the ring.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* Placement handles: the footprint in the preview's blue, the idle handle steps back
The footprint drawn while the marker drags is a filled shape in the preview's own blue with a thin darker edge, not a white outline, so white stays reserved for what can be grabbed. While one handle is dragged the other fades to a quarter and comes back when the drag ends.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* Placement handles: the ring in the preference text, the docs and the tests' wording
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* Placement handles: the look as tuned in the app
Marker: drawn to the redrawn design (dot r 3.9 pt, two dashes per arm, a filled head 8.7 × 7.1 pt whose base is where the outer dash began); pointed at, the outer dash becomes the head (its far end narrows to a point, its near end widens); dragging runs the inner dash on into the head as a shaft. Every casing is 0.4 pt outside the edge, for lines, heads and the dot alike.
Ring: the grip and the compass lie in the ring's plane like the circle, so the grip is never skewed against it; the grip is a thick chevron with a hole that flattens into the base as the grip slides onto the ring, and fills; the dotted circle stays while turning, with the solid arc laid over it; opening eases in and takes 0.3 s, leaving is a 0.15 s fade over the resting ring, not the sweep backwards; a drag keeps the angular gap of the press, so the grip does not jump onto the pointer; the compass ticks and the readout's point name are in their axis colours, and the grip takes the axis colour (eased) while aligned with one, with that point's tick left out; free turning keeps a hair of pull (0.5°) so an axis can still be hit; the readout wraps to a half turn.
Value box: with a ring it keeps out of the circle the ring, grip, compass and readout sweep, one place per view, nothing moves when a turn starts; also when the value does not evaluate and there is no arrow.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* Placement handles: the readout shows a half turn as 180°, not −180°
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* Placement handles: the motions in one place
The animations the handles grew (a factor eased in and out each way on its own time and easing, a handle stepping back while the other works, a colour that comes and goes from the last one it was on, the gap a press keeps for its drag, an offset that slides instead of jumping) move out of place_gizmo into motion.rs, so the next manipulator reuses them. The look's timings become Transitions in look.rs. No change in behaviour: the contact sheet before and after is identical, the harness tests stand.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* Placement handles: the axis colours as main names them since #4430
The compass and the aligned grip take the one set of X, Y and Z colours (axis_x, axis_y, axis_z); the Move gizmo's own array is gone.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
* Frames: a Weldments ribbon tab (#4003)
- WELDMENTS joins the ribbon after SHEET METAL and is built the same way:
Sketch (New Sketch), Create (Frame Member) and Configure (Parameters,
Configurations). Frame Member's home moves there from MODEL > Create.
- Always shown, as a frame starts from a sketch of its lines. It selects
itself and takes the contextual style when the selected body (or the last
body of the active component) is a frame member; sheet metal comes first.
- It uses the default accent until the palette has a colour for it.
- The tab label is in every catalog; docs/ribbon-layout.md, docs/frames.md
and the tab list in docs/control-protocol.md follow.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Frames: Weldments keeps the ordinary tab look (#4003)
Weldments still selects itself when a frame member is the active body, but
no longer takes the solid contextual fill or the 2 px accent line under the
tab row: selected, it looks like a selected Model tab. Only Sketch and Sheet
Metal (on a sheet body) are contextual.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* claim: #5853
* Batch: refuse a step that would fail at its turn before the first step runs (#5853)
engine.batch and the MCP batch tool checked only a batch's shape up
front. A misspelled command id in a late step was found at its turn,
after every earlier step had run, and then all of it was rolled back: a
160-step batch with a typo as its last step ran for a minute and
changed nothing.
solidcraft_engine::batch_preflight::check finds, before anything runs,
the first step the batch would certainly refuse at its turn: a step
without a command, an unknown command id (the error names the closest
ids, as at the step's turn) or, with strict parameter checking, a call
that breaks its command's typed contract. Anything that depends on the
design is left to the step's turn.
- engine.batch (control channel) checks against the app's registry and
its session's level; view.pick, which the app answers itself, passes.
- The MCP batch tool checks when the commands run in its own process
(headless, with --param-check from the backend). A running app may be
another version with other commands and checks the batch itself; its
reply's not_run is passed on.
- The refusal is the failing step's reply with completed 0, undone 0,
not_run listing every step and a note.
Tests that used an unknown command only to make a late step fail now
use a step that fails at its turn (a bad extrude distance), so they
still test rollback, timings and file.new as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FN5eEMrqWWXqi65FcK8GXq
---------
Co-authored-by: sascha2101 <221609842+sascha2101@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* claim: #6646
* Control channel: document.revision, a design revision and a document id (#6646)
A program that follows the open design asks document.revision and exports
only when the answer moves: document_id names the open design (kept through
edits, saves and renames, another for each design started or opened, never
shared between two tabs or two runs) and revision moves whenever the design,
what is hidden or an uncaptured component position changes. It stays put on
reads, selections and view changes, unlike the session's view revision.
The revision is read lazily: the session remembers the design it last
reported (held weakly, so Arc::make_mut can never change it in place and its
address can't be reused) and takes a new number from one counter for the
whole run when the design is another one. The control method answers at once,
also while a slow command computes; engine.execute reaches the same command
for scripts and MCP.
* document.revision: hash the run's id prefix with the process's random keys
A clock set before 1970 gave every run the prefix 0, so a restarted app could
answer a new design with the id and revision of the old one. The docs no
longer promise an answer at once: a screenshot waiting for an opened design to
be meshed still holds the requests behind it.
* document.revision: its label in the complete catalogs (ja, zh)
* claim: #6985
* Control channel: control.subscribe and design.changed events (#6985)
A connection that sends control.subscribe gets the active design's id and
revision in the reply (as document.revision answers), then a
{"event":"design.changed","params":{document_id, revision}} line whenever
either changes, so a live link need not poll.
The window publishes the design at the end of each frame's logic and
drawing while a connection is subscribed (one atomic load otherwise). Each
subscribed connection waits on that from a thread of its own and writes
the latest after a 100 ms gap, so a burst of changes is one line. Replies
and events share one lock per connection, each written whole (#6390).
* control.subscribe: the reply before any event, a second one refused
The events thread started before the subscribe reply was written, so a
change right after the window's answer could reach the client before the
reply that named the older revision. The subscription now starts holding
the connection's line lock and writes the reply under it.
A second control.subscribe on a subscribed connection is refused on the
connection itself: its answer could arrive behind a newer event. When no
thread or socket is left for the events, the reply says it did not
subscribe instead of ok.
* control.subscribe: a second one does not lose a finished late reply
The already-subscribed answer came before the busy check, so a request that timed out and had finished since lost its reply: control.pending then said the app ended it without one. It now comes after the busy check and drops a finished late reply as every other request does.
* control_server: declare the subscribe guard at the top of the loop
Clear of the lines #6643 changes (its token check moves to where the declaration was).
* control_server: the subscription's items beside serve
Away from the lines next to send, where #6643 adds token_of.
* control test: New on a blank design reuses its tab, so redo the box first
---------
Co-authored-by: MateuszSychXpl <151755914+MateuszSychXpl@users.noreply.github.com>
* claim: #4846
* Assistant: say so when a turn ends without using SolidCraft's tools
When tools were offered and a completed turn made no tool call and no
change, the chat panel shows a short notice pointing to tool-capable
models: always for an empty reply, and for a text-only reply to an
explicit edit request. Plain answers to questions stay quiet. The
control channel exposes it as turnWarning.
* Fix the Anthropic loop test for the tools event; add ja and zh for the no-tool-call notice
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: bherbruck <brennen.herbruck@gmail.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* claim: #4146
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Viewport theme: a light 3D view in a dark window, and the reverse (#4146)
Preferences › Interface › Theme gets a Viewport row under the theme tiles:
Follow theme (the default, as before), Light or Dark. Light or Dark draws
the 3D view in the built-in Light or Dark theme's colours whatever the
window uses, so a dark window can show the model on a light view and the
other way round; it works with every theme, theme files included.
The view takes the background and grid, bodies, selection and hover, the
origin, previews, sketches with their dimensions and glyphs, the navigation
cube and triads, box selection and the analysis colours. Panels, dialogs,
menus and the chips over the view keep the window's. Text and warnings drawn
straight onto the view (the sketch status line, the loose-end and midpoint
markers, the section's cut outlines, the 3D sketch tool and the sketch tools'
previews) take the view's side, so they read on its background.
theme::ViewportTheme is the setting (saved as `viewport_theme`: theme, light
or dark; an unknown saved value reads as Follow theme, as ColorVision's
does). Tokens::get() takes the view's colours from the other side only when
the view's dark or light differs from the window's; Tokens::view() is the
view's side for colours drawn onto it. The ground shadow follows the view
(the scene and highlight caches already key on the colours themselves),
ui.render draws in the view's colours, and ui.prefs takes `viewport_theme`
and reports `viewport_dark`. An older release ignores the setting and draws
everything in the theme.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Viewport theme: follow the single set of axis colours
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: bherbruck <brennen.herbruck@gmail.com>
* claim: #4846
* Warn when Ollama models lack tool support (#4846)
Check Ollama model capabilities in the background and cache results per
endpoint and model. Show an advisory warning for models without tools,
expose it through ui.agent_chat, and document the behavior.
Cover capability parsing, warning selection, background probing, caching,
and selection changes with synthetic regression tests.
* Keep the Ollama capability probe out of the web build
The panel never calls it there, so it would only be dead code.
* Wrap the model warning instead of cutting it off
In a narrow panel the end of the sentence, the part that says what to do, was truncated.
* Fix AgentConfig default after rebase onto main
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Move the Ollama no-tools warning into a pending locale file with ja and zh
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: bherbruck <brennen.herbruck@gmail.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
When an agent's models come from several providers (Hermes and OpenCode
name each one "Provider · model" or say "Provider: ..." in its
description), the chat header shows a provider drop-down before the model
drop-down, and the model drop-down lists only that provider's models
without the provider in front. It opens on the provider of the model in
use; picking a provider alone changes nothing. ui.agent_chat takes
provider and reports providers and provider.
* claim: #2320
* Value fields step with the arrow keys and the mouse wheel (#2320)
Up/Down in a focused value field step a plain number by 1 in the unit it is written in
("20 mm" -> "21 mm", "2,5 mm" -> "3,5 mm"), 10 with Shift and 0.1 with Alt; the wheel over
the focused field does the same, a step a notch, instead of scrolling the panel under it.
Expressions such as `width / 2` are left as typed, and an open completion list keeps the
arrows. Every expression field gets this through `params_dialog::complete`: the value box
beside the geometry in every dialog, the dialog rows, sketch dimensions, the dimension
editor, Drive Joint and the Parameters window.
* The value box beside the geometry stays under the pointer
The box rides on the arrow's tip, so each wheel notch that stepped its value moved it, and
after a notch or two the box slid out from under the pointer and the wheel zoomed the view
instead. While the pointer is over it the box now keeps its place, and it goes back to the tip
when the pointer leaves.
* Value stepping is a preference, off by default
Preferences › General › "Step values with the arrow keys and the wheel" (`step_values`,
also through `ui.prefs`) turns on Up/Down and wheel stepping in value fields, and the value
box staying under the pointer while the wheel steps it. Off, as by default, value fields
behave as before: Up/Down move the text cursor, the wheel scrolls, and the box beside the
geometry follows its arrow.
* Value stepping test: Bend Radius is under Advanced now
* Value stepping test: the preference is on the Design page
* Value stepping test: draw the field straight into the test's frame (#2320)
The shared outer-host rule now covers tests too; the field needs no panel around it.
* claim: #5467
* Warn when a design is open elsewhere or changed on disk (#5467)
The desktop app keeps a lock file next to each open design
(.~<file>.lock: computer, user, version, opened and refreshed times),
refreshes it every minute and removes it on close; a lock not
refreshed for three minutes is stale and ignored. Opening a design
that another SolidCraft has open asks: Open Read-Only, Open Anyway or
Cancel. A read-only design saves only to another file.
A design remembers its file's size and modification time when it is
opened or saved. Save over a file another program or computer changed
since asks: Save a Copy (the default), Overwrite or Cancel.
Programmatic calls never ask: doc.open reports open_elsewhere and takes
read_only, and file.save over a changed file returns an error until it
is given overwrite: true. ui.documents answers both questions.
* claim: #5822
* Batch: consecutive parameter edits can rebuild the design once (#5822)
An agent's batch of parameter edits, one parameter per step, evaluated the
design once per edit: an edit early in the timeline rebuilds nearly all of
it, and 21 such edits ran for minutes.
engine.batch and the MCP batch tool take coalesce_parameters (default
false). With it, each run of consecutive plain parameter edits
(parameters.change with only a name and an expression, or with changes) is
set as one parameters.change {changes}: one rebuild for the run. Any other
step ends a run, so later steps see the design up to date. Every step
still gets its own result (coalesced: the run's length); the run is one
undo step. A run whose combined edit is refused (a new parameter, which
changes can't make; a bad expression) runs step by step, so a refused edit
is still named by its own step. The app's off-thread evaluation computes
the run the same way. The grouping is solidcraft_engine::batch_params,
shared by both runners.
21 parameter edits on a plate with 21 extruded bosses (in-process MCP,
ci profile): 40.1 s step by step, 3.5 s coalesced, the same volume.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Batch coalescing: say a run skips the states between its edits; test it against step by step (#5822)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* claim: #6304
* view.pick: map screenshot pixels to exact geometry (#6304)
A read-only command that answers, for screenshot pixels (window or model
frame) or world-space rays: body, face index, exact world point and
outward normal, depth, occurrence/component for placed parts, and the
nearest edge/vertex within edge_px. Faces are raycast through the same
per-body pick index the mouse uses; flat faces are solved exactly
against their plane, curved faces take the mesh hit with the normal
interpolated from the mesh's surface normals. Section-aware: faces on
the removed side do not stop a pick and the cut cap answers with
section_cap. Never touches the selection, camera, document or undo.
Exposed as control ui.pick and as view.pick through engine.execute and
engine.batch (and through them MCP execute and batch).
---------
Co-authored-by: Dahak Builds <dahakbuilds@users.noreply.github.com>
* Performance overlay: frame-time graph and histogram, triangles, draw calls (#2548)
Net change of the perf-overlay branch, rebased onto main as one commit.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Document frame_rate_details in ui.prefs
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: bherbruck <brennen.herbruck@gmail.com>
* claim: #5009
* Assistant: a request timeout per endpoint for slow models (#5009)
An OpenAI-compatible endpoint now stores how long one model request may
take (request_timeout_s, 300 s by default, clamped to 30 s ..= 1 h). It
is set in the Add agent dialog and in the endpoint's entry under Agents
(a running conversation uses a change from its next request), through
ui.agent_chat add_agent, and reported in the chat's state. A request
that runs out of time says the limit and where to raise it instead of
"timeout: global". The desktop HTTP cap goes from 900 s to an hour.
The tool-call timeout stays 330 s: it covers SolidCraft's own tool work
and the user's Allow, never the model.
* Assistant settings: line up an endpoint's Request timeout with Permissions
The label column of an agent's entry is wide enough for "Request timeout",
so the label isn't cut and both rows share one column.
Open or close every Browser folder from the design or a component menu,
including folders that start closed. Display only: not saved, not an undo step.
* claim: #4664
* Control: name the token file and spot a stale one when a call is unauthorized (#4664)
When the app refuses a token that the MCP client read from a token file,
the error now names that file, when it was written and how long ago,
without printing the token. The app also writes `<port>.pid` beside the
token file (its process id and, on Linux, its start time) and removes
both at exit; when that process has exited, the error says the token
file is stale. The process check runs only after a refusal, and the
token file itself stays one line, so existing clients keep working.
Document force-quit leftovers and the MSIX AppData redirection.
* Bench assistant: read the token out of the new ClientToken
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
---------
Co-authored-by: bherbruck <brennen.herbruck@gmail.com>
Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
The Origin folder's eye, a finished sketch's Show Profile and Show Dimensions,
and body locks move from UiState into the design's saved visibility
(origin_hidden, hidden_profiles, shown_dimensions, locked_bodies), so each tab
keeps its own and they survive closing the design. The Sketches folder uses the
saved browser folder (c0/sketches in hidden_folders); ui.set/ui.inspect keep
showOrigin, showSketches, hiddenProfiles, shownDims and lockedBodies.
Preferences > Design > "Hide origin by default": a design that never toggled
its Origin eye follows the preference. New fields are a pending format change
(format/pending/browser-view-state.rs).
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* claim: #2224
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* Agent chat: keep Send in view for a long message, open "View attached" (#2224)
The message box sat in a fixed 92-point reserve, so a long message grew it
past the panel and took Send, Stop and Attach view with it. The box is now a
panel of its own at the bottom: it grows upwards up to a cap, then scrolls,
and the conversation takes what is left.
The picture sent with a message is kept on it (once the agent starts on the
message), and the "View attached" caption opens it in a window.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* Agent chat: a message's pictures as thumbnails with a hover preview and a viewer (#2224)
Instead of a window on the far side of the screen: the pictures of a message
show as small thumbnails under it, hovering one shows it bigger for as long as
the pointer stays, and a click opens a viewer over the app with the message's
pictures one at a time (previous and next, arrow keys, Esc). A picture carries
a note shown with it, so attachments of other kinds can use the same viewer.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* claim: #2286
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* Agent chat: Attach selection sends what is selected in the model with the message (#2286)
A checkbox beside Attach view. The selection is read when the message is
sent (also for a queued one) and described: faces and edges with the names,
indices and points the tools take plus their size and place, features by name
and kind, bodies by name; at most 64, the rest counted. The agent gets it as
text after the message; the conversation shows the message as typed with the
things as grouped chips (hover for what the agent was told).
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* WIP: the chat's context picker dialog (#2286)
* Agent chat: Pick context, a picker for elements, features and bodies (#2286)
A button beside Attach selection opens the picker: a dialog with Elements,
Features and Bodies inputs, so clicks in the model, the timeline and the
browser pick into the active one (clicking again takes one out), with the
usual highlight. OK puts the picks as chips with an x above the message box;
they go with the next message like an attached selection (text for the agent,
chips in the conversation) and the tray is empty again afterwards. Cancel
keeps what was picked before. The control channel opens it with pick.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* Agent chat: Attach selection counts and describes what was clicked, not the pieces of a rim (#2286)
A click on a circular rim or a split surface selects all its pieces for the
commands. The checkbox counted them one by one and the agent got one entry
per piece (reported on macOS). They are now grouped back into the click they
came from: one chip, one entry with the whole size, and the indices of every
piece in its detail. Edge details are looked up by position as well as
index.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* Agent chat: a message's picture is kept on exactly that message (#2224)
The turn now carries its message's place in the conversation (also through a
queue and a send again after a sign-in), so its picture is kept there, once,
and never on an older message that also wanted one (review of #2225).
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* Agent chat: use the UI kit's checkbox and button and the font tokens (guard tests)
Main's UI-kit guard tests reject raw egui checkboxes, buttons and font sizes in the
chat panel; Attach selection, Pick context, the chip remove button and the chip fonts
now come from ui_kit and Tokens.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
Co-authored-by: bherbruck <brennen.herbruck@gmail.com>
* claim: #3083
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WIP: choose the window system on Linux in Preferences (#3083)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Preferences: a window system set over the control channel is saved for the next start again
The merge kept main's check in ui.prefs, which only looked at the anti-aliasing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Preferences: the window system section drops the restart badge its note already states
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
froglemonade2