The editing pipeline

EditTarget is what is being edited: some objects, the document their changes are recorded in, and an IEditProvider that says how to reach their members. EditProperty is one member bound to all of them — read it, write it, and the write is an undo entry. EditValue is what a read answers with, which is either a value they all share or the fact that they disagree.

Underneath, IEditMember is the narrow contract a provider hands back: a name, a type, a read, a write, and the command that makes the write undoable. SetValuesCommand is that command for anyone who has no typed accessors to offer, so an implementation gets merging and per-object old values without writing either. InspectorEditProvider is the first real provider, over the descriptors the inspector's generator emits; NodePortEditProvider is the second, over a graph node's ports — see editing a node's ports.

⚠ InspectorEditProvider answers for two registries, and it used to answer for one. [Inspector] describes a type explicitly; the serialization generator describes every [DataContract] type anyway, and ReflectedDescriptor builds an inspector descriptor out of the second where the first has no entry. Reading only the first made the pipeline strictly narrower than the panel that draws it — a settings asset, which is this interface's own worked example for why the seam exists, drew rows on screen and answered with an empty member list through an EditTarget. That means no EditProperty, no undo, no mixed state and no markup binding, and it was silent in the direction that looks fine: an empty list is a target with no properties rather than an error. The fallback costs a second dictionary lookup on the miss path and is cached; nothing about it is a reflection pass, because TypeRegistry is filled by a module initializer the generator emitted.

GizmoDrag and GizmoEdit are the same idea at the other end of the editor: a finished drag, and the entry it turns into together with the history that entry belongs on.

Every surface that changes something has the same four problems — undo, editing twenty objects at once, showing that the twenty disagree, and telling everything else that a value moved. Solving them per surface is how an editor ends up with five commands, five answers to "what does a mixed selection show", and a plugin that cannot join the undo stack at all because there is no shared thing to join.

⚠ The concrete consequence is that a plugin gets all four for free. A panel written outside this repository builds an EditTarget over whatever it is showing and writes through it; the entries land on the same stack as the inspector's and the viewport's, in the order they happened, and Ctrl+Z takes them back in the same order.

It is also what markup binds against. A .vxml attribute naming a member has to resolve against something that is not a C# type — EditTarget.Find is that something, and a graph node's ports are the case that proves it: they are members of nothing, and a <PropertyField Path="Base Colour" /> reaches one anyway.

You do not want it for state that is not an edit. A camera's position in a viewport, a panel's scroll offset and which foldouts are open are not things anybody expects Ctrl+Z to touch.

Build a target over the selection, ask it for a property by name, and write.

⚠ Seal is what ends a run of merged edits, and it is explicit rather than a time window. A window makes how many undo steps a drag produced depend on how fast somebody moved a mouse, which is neither predictable for the user nor testable without a fake clock. Call it on mouse-up and on focus loss.

⚠ Wrap the write-back with Refreshing when you put a value into a control. Setting a control's value raises its own changed event, which calls Write; that is harmless when the value is the one already held and destructive when the property is mixed, because a mixed property has no such value and the control's neutral position would be written to everything selected.

Describing your own type. Implement IEditMember per member and IEditProvider over the set; SetValuesCommand supplies the command, so undo, merging and mixed-value editing come with it.

⚠ Derive from InspectorMember instead when the members are to be drawn. The narrow contract below is enough to read and write; it is not enough to get a row, a drawer or a reset button, because those are the inspector's own vocabulary. NodePortMember is the worked example — see editing a node's ports.

Editing one leaf of a struct across a selection. Write sets every object to the same value, which is wrong for a nested value type: nudging twenty objects along X would give them all the first one's Y and Z. WriteEach says what each object gets, as one undo entry.

Recording a drag. A gizmo target says what its drag was and where the entry belongs, so a viewport does not hold a list of which target kinds are exceptions to its rule.

⚠ The stack comes back with the command rather than being assumed. A proxy shape dragged in an animation panel belongs to the shape set's file and its entry belongs on that file's history — not on whichever scene happened to be showing it, which would make undoing it depend on which tab had focus.

* The editor shell — the command registry every entry ends up in * Editor modes — what a gesture means before it becomes an edit * Inspectors in markup — binding a .vxml tree against an EditTarget