Introduce ViewConstraint and layoutWithConstraint

[jdolan]

ObjectivelyMVC's layout engine has had some fundamental issues for years. Namely, there are two ViewAutoresizing bits that pull in opposite directions: Contain and Fill. Scenarios where a child specified Fill and a parent specified Contain are ambiguous.

There was also a staleness bug in StackView that did not re-compute remaining size while laying out subviews. These sorts of bugs led to layoutSubviews not being idempotent.

This branch aims to fix these problems by introducing the concept of constraints, where a parent negotiates each child's size before proceeding to layout. It allows bottom-up size requests to propagate upward before top-down layout clobbers them.

[Copilot]

🟡 Changes recommended

The new constraint pipeline introduces at least two confirmed behavior bugs (standalone relayout can force an axis to 0, and Panel’s contentView height constraint is ignored), which can cause incorrect layout at runtime.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Introduces a constraint-based sizing pass (ViewConstraint, sizeThatSatisfies, layoutWithConstraint) to make layout idempotent and to resolve historical ambiguity between Contain and Fill, while also fixing StackView measurement staleness by measuring subviews fresh per layout pass.

Changes:

• Add ViewConstraint + new sizing/layout APIs (sizeThatSatisfies, sizeToSatisfy, layoutWithConstraint, layoutWithSize) and wire them into the default View layout pipeline.
• Update key containers (e.g., StackView, Panel, CollectionView) to use constraint/size-driven layout entrypoints instead of resize + layoutIfNeeded.
• Add a new View test suite covering the previously ambiguous and stale measurement scenarios; update CSS to add explicit min-width floors for widgets relying on contain/fill behavior.

File summaries

File	Description
Tests/ObjectivelyMVC/View.c	Adds layout regression tests for contain/fill ambiguity and StackView staleness/idempotency.
Tests/ObjectivelyMVC/Makefile.am	Registers the new View test binary in autotools test runner.
Tests/ObjectivelyMVC/.gitignore	Ignores the new View test executable.
Sources/ObjectivelyMVC/View.h	Defines ViewConstraint and documents/declares new sizing/layout APIs.
Sources/ObjectivelyMVC/View.c	Implements constraint-based sizing/layout and updates default layout behavior to use it.
Sources/ObjectivelyMVC/TableView.c	Adjusts sizeThatFits to avoid returning expensive natural size when not acting as a container.
Sources/ObjectivelyMVC/StackView.c	Fixes stale measurement by measuring subviews fresh and laying them out via layoutWithSize.
Sources/ObjectivelyMVC/Panel.c	Switches content view layout from direct resize to constraint-based layout.
Sources/ObjectivelyMVC/CollectionView.c	Uses layoutWithSize for dictated item sizes during layout.
ObjectivelyMVC.xcodeproj/xcshareddata/xcschemes/ObjectivelyMVC-View.xcscheme	Adds an Xcode scheme for the new View-focused test/target.
ObjectivelyMVC.xcodeproj/project.pbxproj	Adds the new ObjectivelyMVC-View target and related build settings/dependencies.
Assets/stylesheet.css.h	Updates embedded stylesheet bytes/length for CSS changes.
Assets/stylesheet.css	Adds min-width rules (e.g., Slider/TextView) to ensure contain sizing has a non-zero floor.

Review details

• Files reviewed: 13/13 changed files
• Comments generated: 4
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟡 Changes recommended

Confirmed layout regressions in StackView positioning/alignment relative to padded bounds and build-setting overrides in the Xcode project need to be fixed before merge.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (3)

Sources/ObjectivelyMVC/StackView.c:182

• When aligning subviews on the secondary axis, StackView uses coordinates relative to 0 instead of bounds.x / bounds.y, so horizontal/vertical alignment ignores padding. Also, pos is advanced using the requested size (subviewSize.*), which can diverge from the actual clamped size in subview->frame.*, leading to gaps/overlaps.

        case StackViewAxisVertical:
          switch (subview->alignment & ViewAlignmentMaskHorizontal) {
            case ViewAlignmentLeft:
              subview->frame.x = 0;
              break;

Sources/ObjectivelyMVC/StackView.c:196

• When aligning subviews on the secondary axis, StackView uses coordinates relative to 0 instead of bounds.y, so vertical alignment ignores padding. Also, pos is advanced using the requested size (subviewSize.w) instead of the actual clamped subview->frame.w, which can misplace subsequent subviews.

        case StackViewAxisHorizontal:
          switch (subview->alignment & ViewAlignmentMaskVertical) {
            case ViewAlignmentMaskTop:
              subview->frame.y = 0;
              break;

ObjectivelyMVC.xcodeproj/project.pbxproj:1582

• These build settings override any inherited linker flags/search paths, which can break builds when the project/xcconfig expects $(inherited) to be preserved. Mirror the other targets by using the array form and including $(inherited).

				LIBRARY_SEARCH_PATHS = "$(HOMEBREW_PREFIX)/lib";
				OTHER_LDFLAGS = "-lcheck";
				PRODUCT_NAME = "$(TARGET_NAME)";

• Files reviewed: 15/15 changed files
• Comments generated: 2
• Review effort level: Lite

[jdolan]

Subview frames in ObjectivelyMVC are relative to the superview's padded content origin, not its unpadded frame: View::renderFrame adds superview->padding.left/top when resolving absolute coordinates (View.c, renderFrame), so a subview at frame (0, 0) already renders inside the padding. Offsetting by bounds.x/y here would apply padding twice. The default View::layoutSubviews follows the same convention (subview->frame.x = 0 for left alignment). Leaving the code as is.