Module features 

Map kernel feature schemas to the shared FormField representation.

Feature definitions come from brep_kernel::feature_schema_catalogue. Parameters map to scalar, text, vector, choice, boolean, and reference fields; a boolean operation expands into operation, tool-selection, and merge fields. Transform start references are not surfaced here.

Functions

feature_catalogue

The kernel-owned feature-schema catalogue ({ version, features: [...] }). A clone of the process-wide cache: callers that only READ it (the palette, the workbench toolbar, the context bar) pay one clone per call instead of the whole construction.

feature_default_params

A feature type’s DEFAULT inputParams, built from its schema: one entry per inputParamsSchema param seeded with that param’s default_value (missing → null). The caller assigns the unique id afterwards (the schema’s id default is null). Additive, engine-owned, and reusable by any “add feature” path so a new feature’s params always track the kernel schema. Unknown types yield an empty object.

feature_form_fields

Map a feature type’s inputParamsSchema into the general form fields, in schema (insertion) order — the kernel builds schemas with serde_json’s preserve_order, so grouped fields stay contiguous for the group headers.

feature_hidden_params

The param keys this feature’s dialog should HIDE for the given CURRENT values — the kernel’s field-visibility hook (brep_kernel::feature_hidden_params), returned as a set so the form engine can skip a field in O(1). Empty when the feature declares no hook, so every field stays visible. The form engine recomputes this each frame from the live params, which is what makes fields appear and disappear as their governing field changes.

feature_icon

The icon character for a feature type, if one exists. Every kernel feature type has a FreeCAD-inspired monoline glyph in the font’s Private-Use block U+E030-E059 (edited as BREP_app/assets/glyphs/*.svg, which are also the source of the inline SVG icon catalog — see BREP_app/src/icons.rs; every_feature_type_has_catalogued_artwork there checks each of these codepoints actually HAS a glyph, which this module’s own test cannot). The font is installed as family "brep_icons" at the HEAD of egui’s fallback chain (crate-side fonts.rs), so a bare returned char renders as the icon.

feature_long_name

Human display name for a feature type: the schema longName (else the type itself), with the feature’s icon character PREPENDED. Every consumer that shows a feature name (add-feature palette, history tree, context-bar offers, dialogs) reads it through here, so the icon appears everywhere with no per-caller wiring — see feature_icon.

feature_plain_name

The same display name WITHOUT the leading glyph — the schema longName, else the type itself.

feature_schema

One feature’s full schema entry, by its type / shortName (e.g. "P.CU", "B"). None if the type is not in the catalogue.

feature_short_name

A feature type’s SHORT name (shortName, e.g. P.CU, S, E), else the type code itself. This is the BASE for a new feature’s id: the engine appends the part history’s persistent global counter to it (P.CU → P.CU7, S → S8) in crate::history::History::next_feature_id.

form_fields_from_schema

Map ANY schema entry carrying an inputParamsSchema object into form fields — the shared engine behind feature_form_fields AND the assembly constraint dialogs (whose schemas come from the kernel’s constraint_schema_catalogue, same shape, different catalogue). One mapping, two catalogues (the schema-driven-dialog principle).

plugin_form_fields_from_schema

Plugin numeric bounds are enforced when the user commits a scalar edit. Keep built-in expression fields on their existing scalar path; neither kind quantizes an authored value just because its form is displayed.