Skip to main content

Crate brep_app

Crate brep_app 

Source
Expand description

Shared eframe application for native windows and WebAssembly canvases. app::BrepApp hosts the renderer and egui in one wgpu frame.

Modules§

app
BrepApp — the THIN shell of the engine-native UI.
automation
The automation layer — the one command channel the app exposes to a host (brep-mcp headless / window, or a dial-in adapter).
column_tree
A tree table with resizable, reorderable, hideable, sortable columns.
delete_selection
What the Delete key / Delete command removes for the current selection (every target). THE delete-selection command: what the Delete / Backspace key, the context bar’s Delete entries and MCP selection_delete all run.
desktop_loop
The desktop event loop: eframe’s winit application plus application-command dispatch that does not wait for a frame (a hidden Wayland window gets none). The desktop event loop.
diagnostics
What this build is running on — the ONE record of it.
document
Open documents and their active tab. Each document owns an engine, store identity, and clean baseline for dirty tracking. Keeping engine access on Documents allows separate mutable borrows of other app fields.
document_class
The three document classes (.nbrep / .fbrep / .tbrep). The three document classes: a normal part (.nbrep), a family seed (.fbrep) and a template (.tbrep).
family_table
A family seed’s table and its Generate (.fbrep). A family seed’s table (.fbrep): one row per member, and the Generate that writes each row out as an ordinary .nbrep part next to the family file.
file_association
Register this build as the system’s .nbrep opener (brep-app --install-file-associations). Native only: the browser has no file association to claim. Register this executable as the system’s opener for its three document classes: .nbrep parts, .fbrep family seeds and .tbrep templates.
fonts
Font setup — the OS’s default monospace font for all text.
form
The generic, schema-driven egui form engine — ONE per-field renderer for BOTH the display-settings dialog AND the schema-driven feature dialogs (the user’s principle: the structure of a thing drives the UI; you don’t rewrite UI code per field, and you don’t write two dialog engines).
form_view
Schema-driven form layout built on form::field_input.
handles
Public handles: the opaque <kind>_<epoch>_<nonce> strings an agent names a document by (the contract’s §3). The epoch is random per process, so a handle from an earlier run is recognisably stale; the nonce is random per object, so a handle cannot be guessed from another. Both are 128 random bits written as 22 characters of unpadded base64url. The app’s own Document::id (a counter) stays the internal key and never leaves the process.
icon_text
IconText — a label that draws catalogued characters as real SVG images, inline with the surrounding text.
icons
The inline-icon catalog: every assets/glyphs/*.svg as SVG source, keyed by the character it draws.
instructions
Manufacturing instructions in the app: making an instructions document from an assembly, the open one or a stored one.
javascript
In-app scratch scripts. Source is saved only on request and never on a model.
logger
The native binary’s log sink (main.rs): RUST_LOG to stderr. Replaces env_logger; the wasm build logs through the browser console instead. The native binary’s log sink: RUST_LOG-filtered lines to stderr.
mcp
The embedded MCP server (brep-app --mcp); native builds with mcp. The embedded MCP server — brep-app --mcp.
offscreen
One egui pass drawn into an offscreen texture: the captures of a pass nothing presents (the desktop loop’s, the browser pump’s). Render one egui pass into an offscreen texture and read it back.
offsite
Features that call another site, on a CAD app hosted by a PLM.
on_demand
One egui pass the app runs itself when nothing is drawing it. One egui pass the app runs itself, when nothing is drawing it.
palette
A generic, reusable searchable command-palette modal — engine-agnostic.
panels
The left-control-panel modules — one file per panel, each following ONE pattern so parallel agents can add a new panel with minimal conflict:
perf
Where a frame’s milliseconds go — the per-frame timing record behind the __brepPerf blob and the Info window’s Performance rows. Where a frame’s milliseconds go — the ONE per-frame timing record.
plm
The PLM client: config, transport, sign-in and the PLM store backend. Inert with no server configured. The PLM client: where the server is, how a request reaches it, and — in client — sign-in, the refusals, the change feed and the version check. Nothing here runs unless a server is configured; the file-based app never constructs any of it.
plugins
Explicit installation and host-only acquisition. Document opening never installs code.
recovery
Autosave unsaved documents under RECOVERY_KEY for recovery at next boot.
report_followup
The problem reports this user submitted, and the notice when one is resolved. Remembering the problem reports this user submitted, and telling them when one is resolved — with no account.
scripting
Scripts in the CAD app: the CAD host for the PLM’s interpreter core (S11). Scripts in the CAD app: the CAD-side host for the interpreter the PLM’s administrator hooks run on (BREP_script_core, plm-cad-integration-todo §3 S11).
simulation_export
A motion study as a video file: GIF (the image crate’s encoder, every frame its own palette, looping) or MP4 (H.264 through the pure-Rust rusty_h264 encoder, muxed by mp4e), at a chosen size and fps.
store
The persistent-storage / filesystem seam — the ONE platform exception in the engine-native UI. Settings, dock layout, and model documents all use the same ModelStore::read / ModelStore::write API. Only its backend differs: desktop writes files; the browser mirrors an ASYNC, swappable mirror_store::StoreBackend — IndexedDB today, a remote server next — into memory and writes behind it, which is what keeps this whole API synchronous.
template
A template’s input marks and its spin-out (.tbrep). A template (.tbrep): a seed whose MARKED expressions are the user’s inputs. Inserting one never places the template: it asks for a new name and the input values, spins out a unique normal part with those values baked into its expressions, and places that.
update
The desktop app’s signed updates from next.brep.io (offered, never silent). The desktop app’s updates: master’s Linux and Windows builds, offered from next.brep.io and installed only with the user’s say-so.
viewport
The 3D viewport — everything that draws + drives the central brep-render scene, split out of the thin app shell.
webmcp
The browser’s tool surface (WebMCP): the MCP server’s tool set, served by the page as the tools it registers with document.modelContext, answered through the automation queue. The pure half compiles natively for its tests; the host and the exports web/webmcp.js imports exist on wasm only. The browser’s tool surface: WebMCP for the wasm build, serving the SAME tool set the desktop MCP server does.
workbench
Per-file WORKBENCH registry — a UI FILTER over feature-CREATION.