You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This commit was created on GitHub.com and signed with GitHub’s verified signature.
Added
arrangement flow (default) - a layout's template block can now nest slots under row/column/grid containers with sizing attributes (width, height, grow, span, gap), and declare when width <compact|regular>[, height <compact|regular>] (or when height ... alone) overrides that replace the tree for a given size class. A bare template of plain slot names still parses exactly as before - this is a purely additive language change.
arrangement freeform - a layout can instead declare variant width <compact|regular>, height <compact|regular> blocks, each placing slots at pixel-precise coordinates with place <Slot> at x,y size w,h (either dimension may be fill) or hiding one with place <Slot> hidden. One screen/data/action/form contract still applies across every variant - only placement varies.
Width/height size classes (compact/regular) are a new two-dimensional vocabulary scoped to layout arrangement, reused across both modes so phone portrait/landscape, tablet, and desktop narrow/wide fall out of the matrix without an orientation primitive.
A freeform layout's variant that omits a slot another variant of the same layout places (or hides) now gets a compile-time warning.
New diagnostics PLAY0233-PLAY0244 for the above, documented in the diagnostics catalogue.
Scope decision: arrangement is declared per-layout, not per-slot. Mixing responsive flow for most of a layout with one pixel-precise freeform region (e.g. a chart in an otherwise-responsive dashboard) is real and common but needs slot-level arrangement - a larger grammar change tracked as a follow-up rather than folded into this PR. Documented as an explicit "out of scope for now" in the new page.
Whether a ui profile targeting a size class with no matching variant/when should warn is a build-time concern (it depends on which layouts a profile's screens actually resolve to) - left to Stage's build pipeline, not the Screenplay compiler.
The CI build (Release) check is expected to fail with CS9057 - a pre-existing, unrelated issue (Microsoft.Net.Compilers.Toolset pinned to 5.6.0, the GH Actions runner's SDK needs 5.9.0+). Confirmed dotnet build/dotnet test pass locally in both Debug and Release.