From 2bc6bdfc777ea64b6f7fa2eea97b8ab923075110 Mon Sep 17 00:00:00 2001 From: iris-ai <4+iris-ai@noreply.localhost> Date: Wed, 16 Sep 2026 18:03:09 -0400 Subject: [PATCH] Let a child with room to move use its own alignment `Stack` and `Pad` forced the near edge on every child. That override exists so a container that reports a child's size and then hands it the box derived from that report does not place its content twice -- and it is owed only where the box really is the child's own answer. `Stack` gives every child the box its sizing child defines. That box is `box_of(child.size())`, so the sizing child has no room in it and needs the override; every other child is handed a box that owes nothing to it, and where it sits in one bigger than itself is its own business. With the override it could not be aligned at all. `Pad` reports its inner's size plus the padding, so where its box is that answer the inset box is exactly the inner and alignment has nowhere to move it. Where the box is bigger -- a share of a row, a rule over the pad -- the slack belongs to the inner, and the override pinned it to a corner. The `tabs` example is the visible case both ways: its counters asked for `Align::RIGHT` inside a stack and sat at the left, and `text`'s narrow panel filled a row it had asked to sit at the top of. Both match canonical `main` again. Neither was noticed when `d3b0ebf` made alignment a property, and the handoff's claim that `tabs` then "differs only in the widget count it prints about itself" was wrong -- it was checked at `8220a78` and not re-checked after the next commit. Checked: fmt, clippy, 81 suite tests, 17 core unit tests, the release oracle at 100 seeds and at 1000 seeds of depth 6, and all fifteen shrinker cases at 400 seeds of depth 5. `tabs`, `text` and `random` change exactly where a child now honours its own alignment; `view` and `minimal` are unchanged. `tabs` is still not `main`'s render: `.sized((100, 100)).center().width( leftover(2))` on one widget no longer means a square centred in a two-share box, because one widget carries one length per axis and `.width` overwrites what `.sized` set. That one is an API question, not a bug, and is open. Co-Authored-By: Claude Opus 5 --- src/widget/position/pad.rs | 8 +++++++- src/widget/position/stack.rs | 10 +++++++++- tests/cases/layout.rs | 29 +++++++++++++++++++++++++++++ 3 files changed, 45 insertions(+), 2 deletions(-) diff --git a/src/widget/position/pad.rs b/src/widget/position/pad.rs index 82d1ba3..7141a4d 100644 --- a/src/widget/position/pad.rs +++ b/src/widget/position/pad.rs @@ -7,8 +7,14 @@ pub struct Pad { impl Widget for Pad { fn draw(&mut self, painter: &mut Painter) -> Size { + // The inner's own alignment, not the near edge. This reports the + // inner's size plus the padding, so where the box is that answer the + // inset box is exactly the inner and alignment has no room to move + // it; where the box is bigger -- a share of a row, a rule over this + // widget -- the slack is the inner's to sit in, and forcing the near + // edge pinned it to a corner it had not asked for. let inner = painter - .widget_aligned(&self.inner, self.padding.region(), RegionAlign::NEAR) + .widget_within(&self.inner, self.padding.region()) .size(); Size { x: LayoutLen { diff --git a/src/widget/position/stack.rs b/src/widget/position/stack.rs index f4c5ca7..8bc3a1c 100644 --- a/src/widget/position/stack.rs +++ b/src/widget/position/stack.rs @@ -29,7 +29,15 @@ impl Widget for Stack { let region = painter.box_of(size); for (i, child) in self.children.iter().enumerate() { painter.child_layer_at(i); - painter.widget_aligned(child, region, RegionAlign::NEAR); + // The sizing child placed its own content in the box its answer + // decided, and this box was derived from that answer, so applying + // its alignment again here would place it twice. Every other + // child is handed a box that owes nothing to its own answer, and + // where it sits in one bigger than itself is its own business. + match sizing == Some(i) { + true => painter.widget_aligned(child, region, RegionAlign::NEAR), + false => painter.widget_within(child, region), + }; } size } diff --git a/tests/cases/layout.rs b/tests/cases/layout.rs index 5b972cf..43a683c 100644 --- a/tests/cases/layout.rs +++ b/tests/cases/layout.rs @@ -499,3 +499,32 @@ fn leftover_children_disappear_at_the_exact_fixed_content_boundary() { assert!(h.region(&a).is_none()); assert!(h.region(&b).is_none()); } + +/// **A stack child smaller than the stack sits where its own alignment +/// says.** `Stack` gives every child the box its sizing child defines and +/// used to force the near edge on all of them; that override is owed only to +/// the sizing child, which has already placed its own content in the box the +/// stack derived from its answer. Every other child is handed a box that owes +/// nothing to it, so where it sits in one bigger than itself is its own +/// business -- and with the override it could not be aligned at all, which is +/// what moved the `tabs` example's counters to the wrong corner. +#[test] +fn a_stack_child_smaller_than_the_stack_keeps_its_own_alignment() { + let mut h = Harness::new((400, 200)); + let big = rect(Color::BLUE).add(&mut h.rsc); + let small = rect(Color::RED).sized((50, 50)).add(&mut h.rsc); + h.rsc + .widgets_mut() + .set_alignment(small.id(), Axis::X, AxisAlign::POS); + let (a, b) = (big.add_strong(&mut h.rsc), small.add_strong(&mut h.rsc)); + let children: Vec = vec![a, b]; + h.set_root(Stack { + children, + size: StackSize::Default, + }); + + assert_corners!(h, big, (0, 0), (400, 200)); + // The far edge on X because it asked for it, the middle on Y because + // that is the default. + assert_corners!(h, small, (350, 75), (400, 125)); +}