geop_ops/ui/mod.rs
1//! What an editor exchanges with the operations while a step is edited.
2//!
3//! An editor never edits a step's arguments itself. It sends what the user
4//! did — a [`StepEditEvent`]: a dialog field used, a click or a drag in the 3-D
5//! viewport as a ray from the eye, a key — to a [`StepEditor`], which
6//! turns it into what the operation understands: a field set to a value, by
7//! the dialog, by a pick in the viewport or by dragging a handle; the
8//! selection changed; a visual dragged in the plane worked in — or, for an
9//! operation with a tool in hand, the click itself ([`CanvasEvent`]). What
10//! comes back is a [`Presentation`]: the operation's [`Form`] — the
11//! [`Dialog`] to show and the [`Visual`]s to draw — with what is picked,
12//! selected and hovered lit. The editor reruns the program with the new
13//! arguments, draws both, and the cycle repeats.
14//!
15//! Operations say what their fields and visuals *mean* — entities that can
16//! fill a [`crate::operation::Role`], a length with a handle, a visual that
17//! can be selected or dragged — and the editor decides how they are
18//! edited, so a pick, a selection or a drag works the same in every
19//! operation.
20//!
21//! So an editor only ever renders generic primitives and forwards raw input,
22//! and every decision — what a click means, what it snaps to, what a drag
23//! changes — is made here, in Rust, where it can be tested: [`hit`] tests a
24//! pointer against visuals, [`PartView`] against the part.
25
26mod dialog;
27mod event;
28mod form;
29pub mod hit;
30mod step;
31pub mod view;
32mod visual;
33
34pub use dialog::{
35 Action, Choice, Control, Dialog, Field, ListItem, Number, Picked, Reference, Tone, Track, Unit,
36};
37pub use event::{Button, CanvasEvent, Pointer, Reach, StepEditEvent, Value};
38pub use form::{Edit, Form};
39pub use step::{DRAG_SNAP, StepEditor};
40pub use view::{Extent, PartHit, PartView};
41pub use visual::{Presentation, Shape, Style, Visual};