Module form_view 

The SHARED schema-driven FORM VIEW — one function that draws a COMPLETE form for a schema-described subject (a history feature, an assembly constraint, a future PMI annotation) and returns what the user did.

form::field_input is the shared per-FIELD renderer; this is the shared per-FORM renderer above it. Before it existed, four call sites hand-rolled their own chrome, grouping and layout around the same widget dispatcher — and the docs screenshot rig’s layout had already silently drifted away from the app’s. One form view means the layout is a ONE-place change.

The layout

  E3  ⟠ Extrude                 ← title
  ─────────────────────────
  ⚠ <error message>             ← banner (only when the subject failed)

  Profile                       ← a reference field: label, full-width
  [ ▣ Select sketch          ]    activation button, and the chosen entities
    • Sketch1            [✕]      listed BENEATH it — never behind a `[+]`

  Distance                      ← every other field: label ABOVE a
  [ 25                       ]    full-width input

  ▼ Boolean                     ← accordion, open by default
  ▶ Transform                   ← accordion, COLLAPSED by default
  ▶ Outputs                     ← read-only, collapsed by default

  [      Return to tree      ]  ← the ONE bottom button

Section order is References → Parameters → the remaining groups in schema order → Transform → the read-only trailing sections. References lead because they are what the user picks and they are the tallest thing on the form; Transform trails because it is the one the owner asked to collapse.

It renders; it does not mutate any engine

The inputs are exactly (ui, spec, &mut params) — no EngineState, no runner, no document. That is deliberate and load-bearing: the headless docs generator (examples/capture_dialogs.rs) has none of those, so requiring one would make “the docs image generator uses the same code as the UI” impossible. Everything that needs an engine — activating the reference picker, acting on a schema button, committing the edited params, leaving the form — comes back OUT as a value in FormViewOut that the calling panel acts on AFTER the draw. (A commit callback would have to capture &mut EngineState while params is itself read out of that engine and the panel already holds it for the frame — three overlapping mutable borrows.)

Transient view state

Which accordions are open is pure view state, so it lives in egui MEMORY keyed by (hits_prefix, title, section) rather than in a caller-owned set — that is what keeps the required inputs at (ui, spec, &mut params) for the headless caller.

Structs

FormViewOut

What the user did in one drawn frame of the form.

FormViewSpec

Everything ABOUT the form that the consumer supplies. Borrowed; the form view holds no state of its own beyond egui memory.

RefActivate

A reference field’s Select was pressed — the caller dispatches this to its own picker flavour (begin_ref_select / begin_ref_select_for_constraint).

Functions

form_view