Struct ProposedChange 

#[non_exhaustive]
pub struct ProposedChange<'a> {
    pub scene: &'a Scene,
    pub items: &'a [ItemId],
    pub op: TransformOp,
    pub start: TransformFrame,
    pub proposed: TransformFrame,
    pub source: TransformSource,
    pub magnet_snapped: bool,
}

A change a gesture is about to make, offered to the geometry constraint.

Every field is a question, never a channel: the answer is the returned ChangeVerdict.

Fields (Non-exhaustive)

Non-exhaustive structs could have additional fields added in future. Therefore, non-exhaustive structs cannot be constructed in external crates using the traditional Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.

scene: &'a Scene

The scene, read-only. Query siblings, guides, parents, magnets, flags — anything a constraint needs to decide.

This is the whole read surface, and the reason a constraint never needs to capture a SceneModel: one that does closes a reference cycle through the closure the scene owns and leaks the scene. A closure that must reach the model holds a WeakSceneModel. Writes panic; see the module header.

items: &'a [ItemId]

The roots this gesture will change, pruned of any item whose ancestor is also in the set — a descendant moves because its root does, so it is deliberately not listed.

The transform controller narrows this further to the roots carrying the operation’s own flag (TransformOp::required_flag); the lightweight item drag lists the whole drag group, which is what it moves.

There is no “primary”: the subject of the decision is the frame, which is what makes the constraint grab-offset invariant. Per-item policy is still expressible — a one-item gesture is items.len() == 1.

op: TransformOp

What the gesture asks of them.

start: TransformFrame

The frame the gesture started from. Fixed for the gesture’s life, so a constraint measures total travel rather than per-sample travel.

proposed: TransformFrame

The frame about to be applied, after magnetism.

Both frames’ rects are stated in the frame’s own basis. For a single rotated item that is the item’s basis, so a grid snap written against rect.x snaps along the item’s axes; a multi-item frame is axis-aligned, so the same rule snaps along the scene’s.

source: TransformSource

Which route produced it.

magnet_snapped: bool

Whether magnetism moved proposed onto a magnet.

The seam where the two snapping systems compose: returning ChangeVerdict::Accept when this is true lets an explicit magnet win over a standing rule. Overriding it is also allowed — and then the magnet’s connection does not fire, because a magnet whose alignment was overruled did not connect anything.

Only the lightweight item drag runs magnetism today, so this is false on the transform-controller, keyboard-nudge and app-driven routes.

Implementations

impl ProposedChange<'_>

pub fn translation(&self) -> Vec2

The scene-space translation from start to proposed.

The quantity an axis lock or a grid snap works in. Exact for a TransformOp::Move; for a resize or a rotate it is the movement of the frame’s origin, and the extent change is in the two frames themselves.

pub fn translated(&self, translation: Vec2) -> TransformFrame

start moved by a scene-space translation — the frame to hand back from ChangeVerdict::Adjust once a move has been rewritten.

The exact inverse of translation, so c.translated(c.translation()) is c.proposed for a move.

Trait Implementations

impl<'a> Debug for ProposedChange<'a>

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.