Skip to main content

Layout

waterui_layout

Trait Layout 

Source 
pub trait Layout: Debug + Any {
    // Required methods
    fn size_that_fits(
        &self,
        proposal: ProposalSize,
        children: &[&dyn SubView],
    ) -> Size;
    fn place(&self, bounds: Rect, children: &[&dyn SubView]) -> Vec<Rect>;

    // Provided methods
    fn explicit_horizontal(
        &self,
        _alignment: HorizontalAlignment,
        _bounds: Rect,
        _children: &[PlacedSubview<'_>],
    ) -> Option<f32> { ... }
    fn explicit_vertical(
        &self,
        _alignment: VerticalAlignment,
        _bounds: Rect,
        _children: &[PlacedSubview<'_>],
    ) -> Option<f32> { ... }
    fn explicit_horizontal_alignments(&self) -> Vec<HorizontalAlignment> { ... }
    fn explicit_vertical_alignments(&self) -> Vec<VerticalAlignment> { ... }
    fn stretch_axis(&self, children: &[StretchAxis]) -> StretchAxis { ... }
}
Expand description

A layout algorithm for arranging child views.

Layouts receive a size proposal from their parent, query their children to determine sizes, and then place children within the final bounds.

§Two-Phase Layout

  1. Sizing (size_that_fits): Determine how big this container should be given a proposal
  2. Placement (place): Position children within the final bounds

§Note on Safe Area

Safe area handling is intentionally not part of the Layout trait. Safe area is a platform-specific concept handled by backends. Views can use the IgnoresSafeArea metadata to opt out of safe area insets.

Required Methods§

Source

fn size_that_fits( &self, proposal: ProposalSize, children: &[&dyn SubView], ) -> Size

Calculate the size this layout wants given a proposal.

The layout can query children multiple times with different proposals to determine optimal sizing.

§Arguments
  • proposal - The size proposed by the parent
  • children - References to child proxies for size queries
Source

fn place(&self, bounds: Rect, children: &[&dyn SubView]) -> Vec<Rect>

Place children within the given bounds.

Called after sizing is complete. Returns a rect for each child specifying its position and size within bounds.

§Arguments
  • bounds - The rectangle this layout should fill
  • children - References to child proxies (may query sizes again)

Provided Methods§

Source

fn explicit_horizontal( &self, _alignment: HorizontalAlignment, _bounds: Rect, _children: &[PlacedSubview<'_>], ) -> Option<f32>

Returns an explicit horizontal guide for this container, if any.

Source

fn explicit_vertical( &self, _alignment: VerticalAlignment, _bounds: Rect, _children: &[PlacedSubview<'_>], ) -> Option<f32>

Returns an explicit vertical guide for this container, if any.

Source

fn explicit_horizontal_alignments(&self) -> Vec<HorizontalAlignment>

Returns the horizontal alignments this container may expose explicitly.

Source

fn explicit_vertical_alignments(&self) -> Vec<VerticalAlignment>

Returns the vertical alignments this container may expose explicitly.

Source

fn stretch_axis(&self, children: &[StretchAxis]) -> StretchAxis

Which axis this container stretches to fill available space, given what its children said about themselves.

A container claims nothing of its own, but it must relay what its children claim: a stack of labels is content-sized, while a stack holding something greedy answers with that child’s axis. A container that stayed silent would be handed its own intrinsic size by its parent, and the greedy child inside it would then fill a box of nothing. A layout that is transparent to its content — a background, an overlay, an alignment guide — answers with that content’s axis, and a frame answers from its own constraints.

children carries each child’s own StretchAxis in order. Passing it is what lets a transparent layout answer from live state: without it such a layout has to copy its content’s axis when it is built, and that copy goes stale the moment the content’s own answer changes — the container then claims space its content no longer wants, or refuses space it now does.

Dyn Compatibility§

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors§