Enum SizePolicy 

#[non_exhaustive]
pub enum SizePolicy {
    Fixed,
    HeightForWidth,
    Intrinsic,
}

How an entry’s local_bounds is decided each layout pass.

The default, Fixed, is what every scene had before this existed: the model owns both axes and nothing measures anything. The other two hand one or both axes to the widget, which is the only thing that can answer “how tall is this text at this width”.

Heavyweight only, and why

A lightweight SceneItem has no layout_response to ask — it publishes its own AABB, and Scene::add_item_dynamic already re-reads that each build. A widget’s height is not a value it publishes; it is the answer to a question asked at a width. So the two mechanisms are not variants of each other, and this one is refused for a lightweight entry rather than silently doing nothing: Scene::set_size_policy returns false.

What is measured, and what is not

A view measures exactly the cards it gives a non-zero size — the ones inside its viewport. Not the ones it keeps alive in the retention band, and not the one the user is interacting with if the camera has left it behind: those are laid out at Size::ZERO, so there is nothing a measurement could be for. A card the camera has never shown keeps the size add_widget_item was handed, and is corrected on the first pass that places it, in the same frame it appears. That is the contract ListView::auto_item_height already makes for rows: the number in the model is an estimate until the thing has been on screen, and every whole-scene query that reads it — scene_rect_extent, the spatial index, a marquee, a minimap — reads the estimate for a card that has never been realised. Give a plausible one; the alternative is measuring every card in the scene on every pass, which is the cost the viewport cull exists to avoid.

The measurement must be idempotent

A measured height feeds back into the model, and the model feeds the next pass. A body whose layout_response answers differently for the same width — because it mutates state, or because its natural height depends on the height it was given — would oscillate forever. The view bounds that, and it is careful about what an oscillation is: 100 → 120 → 100 is one when the body is answering its own last answer, and is a user typing a character that wraps and then deleting it when it is not. The two are indistinguishable from the numbers, and freezing the second is the most ordinary editing action there is.

What separates them is who drove the pass. A body’s answer is a function of its content and of the width it is offered; at a fixed width its content cannot change without something dirtying the card — a Signal bound at Relayout, a rebuild, a fresh node — whereas the view’s own write dirties only the view and what is above it. So on the pass a write causes, the card reads clean, and a clean card that answers differently is reading back what was written to it. The view takes the taller of the two answers, and after a couple of such contradictions stops taking new ones for the rest of the chain — which writes nothing, and a pass that writes nothing schedules no successor. A non-idempotent body therefore costs a bounded number of passes per external event rather than an unbounded number for ever, and an edited one is never bounded at all. See [teksilo_core::widget::Widget::cacheable_layout] for the framework’s own statement of the same obligation.

A resize does not reach an axis the content owns

HeightForWidth keeps its width, so the selection frame resizes it horizontally and the words decide the rest; the vertical half of a corner drag is neutralised in Scene::apply_transform_delta, because a height written there is one the next pass measures straight back over. Intrinsic owns neither axis, so Scene::transformable_roots offers it no resize handles at all. And a measurement taken while a gesture is previewing a transform is placed but never written: the preview is recomputed from the gesture’s frozen start frame each sample, so a previewed width that reached the model would be scaled again on the next one.

#[non_exhaustive]: this crate has out-of-tree consumers.

Variants (Non-exhaustive)

Non-exhaustive enums could have additional variants added in future. Therefore, when matching against variants of non-exhaustive enums, an extra wildcard arm must be added to account for any future variants.

Fixed

The model owns both axes. Today’s behaviour, and the default, so every existing scene is bit-identical.

HeightForWidth

The model owns the width; the height is measured from the widget at that width on every pass that lays it out.

The right policy for text: a note’s width is authored (you drag its edge) and its height follows the words. scene_rect(id).height becomes advisory for such an entry — it reports the last measured height, not the one add_widget_item was handed.

Intrinsic

Both axes are measured: the entry shrink-wraps its widget.

For content that knows its own size on both axes — a pinned label, a badge, a fixed-aspect thumbnail. The rect passed to add_widget_item supplies only the position.

Trait Implementations

impl Clone for SizePolicy

fn clone(&self) -> SizePolicy

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Copy for SizePolicy

impl Debug for SizePolicy

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

Formats the value using the given formatter.

impl Default for SizePolicy

fn default() -> SizePolicy

Returns the “default value” for a type.

impl Eq for SizePolicy

impl PartialEq for SizePolicy

fn eq(&self, other: &SizePolicy) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl StructuralPartialEq for SizePolicy