Skip to main content

Module workbench

Module workbench 

Source
Expand description

Per-file WORKBENCH registry — a UI FILTER over feature-CREATION.

A “workbench” trims the feature-creation UI (the “Add new feature” palette and the selection context bar) and can gate workbench-specific toolbar buttons / panels. It NEVER changes what the feature history executes, renders, or lets the user edit: a document full of sheet-metal features opens and works identically under Modeling. The ONLY things a workbench touches are the palette (see includes_feature) and the context offers.

EXTENSIBILITY is the whole point: a new workbench = one new file here + one entry in WORKBENCHES. No enums to edit. Each file exposes a single 'static Workbench that OWNS its own inclusion decision (includes), its extra toolbar buttons (data only), and the ids of existing panels it claims.

"All" is special: it accepts every feature and its buttons are the DERIVED union of every other workbench’s buttons (workbench_buttons) — never hand-maintained — so adding a workbench automatically grows it.

Modules§

all
The “All” workbench: shows every feature and every toolbar icon.
assembly
The “Assembly” workbench — assemblies build-spec §8.1.
modeling
The “Modeling” workbench (the DEFAULT): general solid modeling.
pmi
The “PMI” (Product & Manufacturing Information) workbench — the mode in which PMI views are captured and annotated.
sheet_metal
The “Sheet Metal” workbench: the sheet-metal feature set plus the shared building blocks.
wire_harness
The “Wire harness” workbench: routed wire runs between PORTs over a network of SPLINE paths.

Structs§

FeatureInfo
The minimal view of one catalogue entry a workbench predicate consumes: the feature type CODE (e.g. "E", "S", "SM.F"), read from the existing app-side catalogue accessor (brep_render::features::feature_catalogue). Each workbench file classifies DIRECTLY off this code (no kernel-stamped category — the kernel stays untouched). Borrows from the runtime catalogue JSON, hence the lifetime — the registry itself stays 'static because the fn-pointer predicate is higher-ranked over the borrow.
Workbench
One workbench: a UI filter + optional toolbar buttons + claimed panels. Fully 'static — fn-pointer predicate and &'static slices, no OnceLock.
WorkbenchButton
A workbench-specific toolbar button, DATA ONLY (no egui, no behavior): the shared toolbar-button helper renders it and a click surfaces id out of the toolbar to the shell, which dispatches on id. Phase 1 ships none.

Constants§

DEFAULT_WORKBENCH_ID
The fallback / default workbench id. Boot-read validation is implicit: resolve maps any unknown stored id to this, so there is no separate boot step — every consumer routes through resolve.

Statics§

WORKBENCHES
Every workbench, in DROPDOWN ORDER: All, Modeling, Sheet Metal. The dropdown iterates THIS — labels are never hardcoded. A new workbench is appended here.

Functions§

includes_feature
Whether a catalogue entry belongs in workbench active_id’s feature-creation UI. The ONE entry point the palette + context-offer filters call: builds a FeatureInfo from the feature type_code and runs the resolved workbench’s predicate (each workbench file owns its classification off the code).
panel_visible
Whether panel panel_id is visible in workbench active_id. Claim-based: a panel is visible UNLESS it is claimed by ≥1 workbench and the active workbench does not list it. "all" sees every panel (mirrors the button union). With v1’s empty panels slices nothing is claimed, so every panel is visible in every workbench — the scaffolding is wired but hides nothing.
resolve
Resolve a (possibly stale / unknown) stored id to a live workbench, falling back to the default. This IS the boot/read validation — route ALL consumers (dropdown display, palette/offer filters, buttons, panels) through here.
workbench_buttons
The active workbench’s toolbar buttons. For "all" this is the DEDUPED UNION of every workbench’s buttons (so “All” shows every icon without a hand-maintained list); for any other workbench it is that workbench’s own buttons.
workbench_by_id
Pure lookup by id — None if there is no such workbench.
workbench_state_json
The workbench list as {id, label} JSON plus the resolved current id — the __brepWorkbench logical-state global the headed verifier reads to drive the dropdown and confirm the active workbench. current is the RESOLVED id (an unknown stored id reads back as the default).