monolith

public

Star0

Fork 0

Watch0

3 commits 1 branch 0 tags 0 releases1.5 MiB

Commit `cd7085e54c88`

tarball

atagen <boss@atagen.co>2026-10-16 07:01 UTC

2 files changed+240-54

design: planner draft 2

Adds the grid construction, which plans any transition in at most four phases and removes the need for a fallback, plus demos for stack joins and leaves, seed shapes and floating windows. Orthogonal style becomes the default.

Modified file: design/decisions.md+8 additions@@ -80,6 +80,14 @@ Running log of settled decisions and open questions. Research backing lives in `
 - Velocity matching is best-effort, applied only where the replan continues the current axis.
 - Launch context resolves through a graceful ranking. Window rule, xdg-activation token, parent toplevel, tracked systemd scope or cgroup, PID ancestry, focus at map time. The target is where the user was when the launch command began. Windows placed on an unviewed tag mark it urgent.
 - Nested sessions are a first-class, permanently supported backend.
+
+### Planner (see `planner.html`)
+- Orthogonal style (one axis per window per phase) is the default and flagship look. Direct is a toggle.
+- Shared-separator rule, plans of 1 to 4 phases, the 4-phase grid guarantees a plan for any input. Pinch and lerp are safety nets only.
+- Window moves and block moves both exist as commands. Tag reordering plans with rigid blocks.
+- One curve per motion group.
+- Floating to tiled is phased. The slot opens concurrently, the floater travels one axis per phase, then lands.
+- Open. Seed shape, whether landing may resize both axes at once, lane extent, and the layout model for interspersed tags.
 - Input hit-tests against final layout geometry, never animated geometry.
 - smithay is pinned by git rev. The repo uses jj.
 

Modified file: design/planner.html+232 additions−54 deletions@@ -34,11 +34,11 @@
 <body>
 <div class="global">
   <label>phase duration <input id="phaseMs" type="range" min="150" max="1500" step="50" value="450"> <span id="phaseMsOut">450 ms</span></label>
-  <label>style <select id="style"><option value="direct">direct (diagonal when safe)</option><option value="orthogonal">orthogonal (one axis per window per phase)</option></select></label>
+  <label>style <select id="style"><option value="orthogonal">orthogonal (default, one axis per window per phase)</option><option value="direct">direct (diagonal when safe)</option></select></label>
 </div>
 <main>
-<h1>monolith planner, draft 1</h1>
-<p class="sub">Design for the multiphase layout animation planner (milestone M1). Every demo runs a small JavaScript port of the proposed algorithm, so what you see is what the design does. Red means two windows overlap.</p>
+<h1>monolith planner, draft 2</h1>
+<p class="sub">Design for the multiphase layout animation planner (milestone M1). Every demo runs a small JavaScript port of the proposed algorithm, so what you see is what the design does. Red means two tiled windows overlap. Orthogonal is the default style, and the selector at the top switches every demo to direct.</p>
 
 <h2>1. What the planner does</h2>
 <p>The layout engine produces a target rectangle for every window. The planner turns "where windows are on screen now" and "where they should be" into a short sequence of keyframe layouts. Each step between two keyframes is a <em>phase</em>. Every window in a phase moves on the same curve and the phase takes exactly <code>t</code>, the configured duration, so a plan lasts <code>phases × t</code>.</p>
@@ -46,13 +46,14 @@
 <ul>
   <li>Tiled windows never overlap while they move.</li>
   <li>Phases are synchronised. Everything in a phase starts and stops together.</li>
+  <li>In orthogonal style, the default, a window moves or resizes along one axis per phase.</li>
   <li>An interrupt throws the plan away and replans from what is on screen. Plans never stack.</li>
 </ul>
 <p>New requirements wry never met.</p>
 <ul>
-  <li>Diagonal moves, moves between outputs, and large groups such as viewing or hiding a tag.</li>
+  <li>Moves between outputs, and large groups such as viewing or hiding a tag.</li>
   <li>Best-effort velocity continuity when an interrupt lands mid-phase.</li>
-  <li>A hard bound on plan length, so interrupts can never produce long animations.</li>
+  <li>A hard bound on plan length, and a construction that never needs a fallback.</li>
 </ul>
 
 <h2>2. The problem</h2>
@@ -61,7 +62,7 @@
 
 <h2>3. The core rule, shared separators</h2>
 <p>For any two windows there are four ways they can be apart. A is left of B, right of B, above B, or below B. Each is a linear inequality on window edges, for example <code>A.right ≤ B.left</code>. If an inequality holds at both ends of a phase and both windows move on the same curve, it holds for the whole phase, because every edge is the same weighted average of its start and end value.</p>
-<p>So the planner's entire job reduces to this. <strong>Pick keyframes so that for every pair of windows, every two consecutive keyframes share at least one separating relation.</strong> Diagonal motion is perfectly safe under this rule. wry needed single-axis steps because its solver checked overlap directly. This rule proves it instead.</p>
+<p>So the planner's entire job reduces to this. <strong>Pick keyframes so that for every pair of windows, every two consecutive keyframes share at least one separating relation.</strong> wry checked overlap after building a plan. This rule makes plans correct by construction.</p>
 <p>Looking at a single pair gives a lower bound on phases.</p>
 <table>
   <tr><th>pair goes from</th><th>to</th><th>minimum phases</th><th>why</th></tr>
@@ -69,11 +70,18 @@
   <tr><td>left of</td><td>above</td><td>2</td><td>needs a middle keyframe where A is both left of and above B</td></tr>
   <tr><td>left of</td><td>right of</td><td>3</td><td>left and right can't both hold, so the pair must pass through above or below on the way</td></tr>
 </table>
-<p>The plan length is the worst pair, so <strong>every plan is 1, 2 or 3 phases</strong>, with one fallback described in section 10. The rule is sufficient, not necessary. Some overlap-free phases break it, and the Rust validator keeps an exact check for those, but the planner only constructs plans that satisfy it.</p>
+<p>Pairs interact, so a whole layout can need one more phase than its worst pair (section 7). <strong>Every plan is 1 to 4 phases, and the 4-phase construction works for any input</strong>, so no fallback is ever required. The rule is sufficient, not necessary. Some overlap-free phases break it, and the Rust validator keeps an exact check for those, but the planner only builds plans that satisfy it.</p>
+<p class="note">Stress test of the JavaScript port. 6,000 random pairs of layouts with 2 to 7 windows, each target a full random reshuffle, in both styles. Zero overlapping frames, zero windows moving on two axes in one phase in orthogonal style, zero fallbacks. Real edits are far smaller than random reshuffles.</p>
 
-<h2>4. One phase</h2>
-<p>Anything that keeps the arrangement of windows intact is a single phase, including changes in both axes at once. That covers ratio changes, inserting and removing windows, splitting a column, and viewing or hiding a tag.</p>
-<p><strong>Seeds.</strong> A window that appears starts as a zero-size rectangle sitting on the edge where space will open. A closing window ends as one. A seed on an edge is already separated from its neighbours, so it obeys the rule from the first frame. wry grew spawns from the centre of their target, which overlaps the neighbours early in the phase while they are still making room.</p>
+<h2>4. One phase, and seeds</h2>
+<p>Anything that keeps the arrangement of windows intact is a single phase. That covers ratio changes, inserting and removing windows, splitting a column, and viewing or hiding a tag.</p>
+<p><strong>Seeds.</strong> A window that appears starts as a zero-size rectangle and grows while its neighbours make room, concurrently, in the same phase. The only question is where it starts growing from.</p>
+<ul>
+  <li><strong>Line on the old boundary</strong> (default). A zero-width line where the two neighbours currently meet. It is always free space, so the whole insertion is one phase in either style.</li>
+  <li><strong>Point at the middle of the old boundary.</strong> Looks like growing from a centre, and never overlaps. Growing from a point changes both axes, so orthogonal style splits it into two phases (grow tall, then wide).</li>
+  <li><strong>Point at the centre of the new window's target.</strong> At the start of the phase that point is usually still covered by a neighbour that hasn't moved out yet. The planner has to push the neighbours away first and grow second. With naive on you see the overlap instead.</li>
+</ul>
+<p>Cycle the seed mode below and insert D to compare.</p>
 <div class="demo" id="d2"></div>
 <p>Viewing and hiding a tag is the same thing at a larger scale. The new tag's windows are seeds on the edge where their row will open.</p>
 <div class="demo" id="d3"></div>
@@ -82,33 +90,60 @@
 <p>When a pair turns a corner (left of becomes above), the middle keyframe is built from a <em>mixed</em> rectangle. Each window takes its horizontal extent from one end and its vertical extent from the other. "X first" means the window takes its target horizontal extent in phase 1 and its target vertical extent in phase 2. "Y first" is the reverse. Every window then moves along exactly one axis per phase.</p>
 <p>Each window's choice is one boolean. Every pair rules out some of the four combinations, and each forbidden combination is a clause over two variables. That makes it a <strong>2-SAT problem, solvable in linear time</strong> with no search. Windows that only change one axis use the same boolean to choose whether they move in phase 1 or phase 2, and the planner prefers phase 1 so nothing waits needlessly.</p>
 <div class="demo" id="d4a"></div>
-<p>The style selector at the top matters here. Growing a window in both directions inside a grid is a valid single phase in <em>direct</em> style, because every pair keeps a relation. <em>Orthogonal</em> style forbids moving a window on both axes in one phase, which gives wry's look of making space first and then growing, at the cost of an extra phase.</p>
+<p>Growing a window in both directions inside a grid. Orthogonal makes space along one axis and then grows along the other. Direct does it in one diagonal phase.</p>
 <div class="demo" id="d4b"></div>
 
 <h2>6. Three phases, lanes</h2>
-<p>Reversals (left of becomes right of) need two middle keyframes. Windows shrink into <em>lanes</em> across the axis of travel, slide past each other, then expand. Two windows may share a lane only if they never pass each other. Windows stacked on top of each other must keep their stacking order in the lanes, at both ends. Picking lanes is a small constrained colouring problem. For a pure reordering of a row the lane count equals the length of the longest decreasing subsequence of the new order (Dilworth's theorem). Swapping two neighbours or rotating needs 2 lanes, and full reversal of four windows needs 4.</p>
-<p>Only windows involved in a reversal enter lanes. Everything else moves in whichever phase validates, preferring the slide phase.</p>
+<p>A <strong>lane</strong> is a temporary strip, like a motorway lane used for overtaking. Before two windows can pass each other along one axis, each shrinks along the other axis into its own strip of the space they share. For a horizontal swap the strips are horizontal, so each window gets a slice of the height. In phase 2 they slide past each other inside their strips, and in phase 3 they expand back to full size.</p>
+<ul>
+  <li>Two windows may share a lane only if they never pass each other.</li>
+  <li>Windows stacked along the strip axis must keep their stacking order in the lanes, at both ends.</li>
+  <li>Only windows that pass something enter lanes. Everything else moves in whichever phase validates, preferring the slide phase.</li>
+  <li>The strips span only the band the involved windows occupy, not the whole output.</li>
+</ul>
+<p>Picking lanes is a small constrained colouring problem. For a pure reordering of a row, the lane count equals the length of the longest decreasing subsequence of the new order (Dilworth's theorem). Swapping two neighbours or rotating needs 2 lanes, and fully reversing four windows needs 4.</p>
 <div class="demo" id="d5"></div>
 
-<h2>7. Tags as rigid blocks</h2>
-<p>Swapping the order of two viewed tags reverses every window of one tag against every window of the other. Planned window by window, that needs one lane per window (5 thin strips in the demo below). Planned with each tag as a <em>rigid block</em>, it needs 2 lanes, and the windows ride inside their block. The block planner is the same algorithm one level up, followed by mapping each window into its block's keyframes.</p>
+<h2>7. Four phases, the grid</h2>
+<p>Some transitions reverse windows along both axes at once. In <code>(A over D) | (C over B)</code> to <code>(A over B over C) | D</code>, D has to pass B and C horizontally while B and C swap vertical order. Lanes along either axis contradict the other reversal. The grid handles it.</p>
+<ol>
+  <li>Every involved window shrinks vertically into its own horizontal strip, ordered by where it starts.</li>
+  <li>It shrinks horizontally into its own column, ordered by where it ends. Every window is now a separate small cell.</li>
+  <li>It moves vertically to its final height. Its column keeps it clear of everything.</li>
+  <li>It expands horizontally to its final width.</li>
+</ol>
+<p>Each step provably keeps every pair separated, whatever the input, so this is the guarantee behind "no fallback needed". It is also the ugliest plan, so the planner only reaches it after everything else fails, and only for the windows involved.</p>
+<div class="demo" id="d9c"></div>
+
+<h2>8. Joining and leaving stacks</h2>
+<p>These have historically been the hard cases. Notation <code>A | B</code> is side by side and <code>A / B</code> is A stacked over B. Click any layout to animate to it from whatever is on screen, including mid-animation.</p>
+<div class="demo" id="d9a"></div>
+<div class="demo" id="d9b"></div>
+
+<h2>9. Rigid blocks and movement commands</h2>
+<p>Swapping the order of two viewed tags reverses every window of one tag against every window of the other. Planned window by window, that needs one lane per window. Planned with each tag as a <strong>rigid block</strong>, it needs 2 lanes and the windows ride inside their block. The block planner is the same algorithm one level up.</p>
+<p>Both movement units exist as commands, for example <code>meta+shift+hjkl</code> moves a window and <code>meta+ctrl+hjkl</code> moves its block. The unit being moved decides the plan. A block move plans with rigid blocks, a window move plans per window.</p>
 <div class="demo" id="d3b"></div>
 
-<h2>8. Interrupts and velocity</h2>
-<p>An interrupt samples the current on-screen rectangles and plans from there to the new target. The new plan has at most 3 phases, however many times you interrupt. Try the storm button, which fires a new target every few hundred milliseconds.</p>
-<p><strong>Velocity.</strong> The base curve starts and ends at rest, so a window that is moving when interrupted stops dead. Velocity matching measures how fast things were moving and starts the first phase of the new plan at that speed, by setting the first control point of the bezier so the initial slope matches. The slope only applies when the first phase continues in the direction things were already moving. Otherwise the window stops and turns, which reads as deliberate. The control point's height is clamped to 1, which mathematically rules out overshoot, since a cubic bezier never leaves the range of its control points.</p>
-<p>One curve per <em>motion group</em>, never per window. Windows that share an edge must move that edge on the same curve or the edge tears open or overlaps. So the group gets a single curve, matched to its fastest mover. The graph shows window A's speed, and turning matching off shows the drop to zero at every interrupt.</p>
+<h2>10. Interrupts and velocity</h2>
+<p>An interrupt samples the current on-screen rectangles and plans from there to the new target. The new plan obeys the same bound however many times you interrupt. Try the storm button, which fires a new target every few hundred milliseconds.</p>
+<p><strong>Velocity.</strong> The base curve starts and ends at rest, so a window moving when interrupted stops dead. Velocity matching measures how fast things were moving and starts the first phase of the new plan at that speed, by setting the bezier's first control point so the initial slope matches. It only applies when the first phase continues in the direction things were already moving. Otherwise the window stops and turns. The control point's height is clamped to 1, which rules out overshoot, since a cubic bezier never leaves the range of its control points.</p>
+<p>One curve per <em>motion group</em>, never per window. Windows that share an edge must move it on the same curve, or the edge tears open or overlaps. Since phases are bounded by time rather than distance, the group's curve follows its fastest mover. The graph shows window A's speed. Turn matching off to see the drop to zero at every interrupt.</p>
 <div class="demo" id="d6"></div>
 
-<h2>9. Across outputs</h2>
+<h2>11. Across outputs</h2>
 <p>Outputs live in one global coordinate space, so a move between outputs is planned like any other move and drawn clipped to each output. The window crosses the bezel and appears on the other side. Moving B over is one phase. Moving A over means A has to pass B, a reversal, so it takes lanes, and the lanes span both outputs.</p>
-<p class="note">Not shown. Outputs at different scales draw the same window at different sizes. The planner works in logical coordinates and each output scales its part. If two outputs aren't adjacent in the global space, the window would travel through empty space, and the pinch fallback is probably better there.</p>
+<p class="note">Not shown. Outputs at different scales draw the same window at different sizes, since the planner works in logical coordinates and each output scales its part. If two outputs aren't adjacent in the global space, the window travels through empty space.</p>
 <div class="demo" id="d7"></div>
 
-<h2>10. Fallback, pinch</h2>
-<p>If no 1, 2 or 3 phase plan validates, the windows that can't be routed shrink to a point, jump invisibly, and grow at their target. That's two visible phases, never overlaps, and always works. I couldn't find a tiling transition in these demos that needs it, but the bound has to hold for every input, including arbitrary floating-to-tiled transitions and malformed layouts.</p>
+<h2>12. Floating to tiled</h2>
+<p>A floating window joining the tiled layout is phased, unlike a spawn. The tiled windows open a slot for it, concurrently and following the same rules as an insertion. Meanwhile the floating window travels above them, one axis per phase, until it sits over the slot. In the last phase it falls into place. Lifting a tiled window back out runs the same steps in reverse. The floating window is drawn above the tiled layer and is exempt from the overlap rule while it travels.</p>
+<div class="demo" id="d10"></div>
+
+<h2>13. Fallbacks</h2>
+<p>The grid construction means no plan should ever need a fallback, and the stress test never reached one. Two remain wired in as safety nets for malformed input. <strong>Pinch</strong> shrinks a window to a point, jumps invisibly and regrows it. <strong>Lerp</strong> interpolates straight to the target and accepts overlap. Which one is the net is a matter of trying both.</p>
 
-<h2>11. Algorithm</h2>
+<h2>14. Algorithm</h2>
 <pre>plan(from, to):
   groups = motion groups (windows whose swept areas can touch, transitively)
   for each group:
@@ -122,61 +157,70 @@
         for k in 2..|set|:
           if lanes assignable with k lanes and all three phases validate:
             return [from, K1, K2, to]                      # 3 phases
-    return pinch(from, to)                                 # 2 visible phases
+    for set in [windows in reversals, all movers, all]:
+      if the grid validates for set:                       # always true for all
+        return [from, K1, K2, K3, to]                      # 4 phases
+    return fallback(from, to)                              # unreachable in theory
 
   rigid blocks: run plan() on block rectangles first, then map windows into them
+  floating:     slot opens via plan() with a seed, floater travels x, then y, then lands
   interrupts:   from = rectangles sampled at the current presentation time
   velocity:     first-phase curve per group, slope from the fastest mover,
                 applied only if moving the same way, control point height ≤ 1
   validation:   exact pairwise check over the curve actually used</pre>
 <p>Cost. Pair checks are O(n²) per group. 2-SAT is linear in clauses, so also O(n²). Lane assignment is backtracking over small sets with a greedy cut-off for large ones. Fifty windows is about 1,200 pairs, which is microseconds.</p>
-<p>Everything here is pure geometry with no smithay dependency, so the <code>planner</code> crate gets property tests. Generate random layouts and random interrupt sequences, then check every frame of every plan for overlap, every plan for ≤ 3 phases, and every interrupt for continuity of position.</p>
+<p>Everything here is pure geometry with no smithay dependency, so the <code>planner</code> crate gets property tests. Generate random layouts and random interrupt sequences, then check every frame of every plan for overlap, every plan for at most 4 phases, every orthogonal phase for single-axis motion, and every interrupt for continuity of position.</p>
 
-<h2>12. Compared with wry master</h2>
+<h2>15. Compared with wry master</h2>
 <table>
   <tr><th>wry master</th><th>this design</th></tr>
-  <tr><td>SingleAction, MixedSinglePhase</td><td>1 phase, now including diagonal moves in direct style</td></tr>
+  <tr><td>SingleAction, MixedSinglePhase</td><td>1 phase</td></tr>
   <tr><td>SpaceThenOrthogonalGrowth, OrientationChange, HierarchyOrderedScales</td><td>2 phases, one 2-SAT problem instead of three strategies</td></tr>
   <tr><td>SwapLanes</td><td>3 phases, general lane assignment for any permutation</td></tr>
+  <tr><td>no equivalent</td><td>4 phases, the grid, for simultaneous reversals on both axes</td></tr>
   <tr><td>ReversedForwardPlan</td><td>not needed, the construction is symmetric</td></tr>
-  <tr><td>Diagonal falls back to overlapping plain interpolation</td><td>diagonal is legal whenever relations are shared, pinch otherwise</td></tr>
-  <tr><td>Bridged retarget can make plans longer than the original</td><td>every replan is ≤ 3 phases</td></tr>
-  <tr><td>Per-phase duration, plans grow with strategy</td><td>per-phase duration kept, plan length bounded</td></tr>
-  <tr><td>Spawns grow from the target centre</td><td>spawns grow from a seed on the opening edge</td></tr>
+  <tr><td>Unplannable groups fall back to overlapping plain interpolation</td><td>every input has a plan, fallbacks are only a safety net</td></tr>
+  <tr><td>Bridged retarget can make plans longer than the original</td><td>every replan obeys the same bound</td></tr>
+  <tr><td>Spawns grow from the target centre</td><td>spawns grow from a seed on the old boundary, concurrently</td></tr>
   <tr><td>Exact rational overlap check validates every plan</td><td>plans are correct by construction, the exact check remains as a safety net and for velocity-shaped curves</td></tr>
   <tr><td>Cross-output moves skip animation</td><td>planned in global coordinates, clipped per output</td></tr>
 </table>
 
-<h2>13. Interspersing tags (new, changes the layout model)</h2>
-<p>Row stacking answers "what does a combined view look like" but not "what happens when I drag A from tag 1's row in between D and E of tag 2". There are four answers.</p>
+<h2>16. Interspersing tags (open, changes the layout model)</h2>
+<p>Row stacking answers "what does a combined view look like" but not "what happens when I drag A from tag 1's row in between D and E of tag 2". There are five answers.</p>
 <table>
   <tr><th>option</th><th>meaning</th><th>verdict</th></tr>
-  <tr><td>Forbid it</td><td>tags stay in their rows</td><td>limiting, as you said</td></tr>
+  <tr><td>Forbid it</td><td>tags stay in their rows</td><td>limiting</td></tr>
   <tr><td>Dragging retags</td><td>moving A into tag 2's row makes A a tag 2 window</td><td>honest and simple, but A then vanishes from tag 1 viewed alone, which is usually not what the drag meant</td></tr>
   <tr><td>2D positional merging (L/C/R × T/M/B)</td><td>windows merge into slots by position</td><td>kill it. Users must predict an implicit rule, and every edit in a combined view is ambiguous about which tag's tree it changes</td></tr>
   <tr><td>Layout per view combination</td><td>each set of viewed tags gets its own tree, seeded by row stacking</td><td>no surprises between views, but N combinations of trees to keep in sync, and every new window has to be inserted into all of them</td></tr>
   <tr><td><strong>One tree per output, tags filter it</strong></td><td>every window of every tag lives in a single tree per output. Viewing tags shows a projection with hidden windows collapsed. Each tag starts as its own row, so row stacking becomes the default arrangement instead of a merge rule</td><td><strong>recommended</strong></td></tr>
 </table>
-<p>The last option is dwm's model (one client list, tags as a filter) with a tree in place of the list. Its advantages are one source of truth and no sync problem. Interspersing is just moving a window in the tree. And for the planner, <strong>viewing or hiding any tag is always a single phase</strong>, because hidden windows are zero-weight seeds sitting at their own spot in the same tree. Switching views never rearranges anything.</p>
-<p>Its cost is action at a distance. Intersperse A into tag 2's row below, then view tag 1 alone. A now sits under B and C, because in the tree it lives in the lower row. You changed tag 1's single view without ever viewing it alone. That's consistent, but some will find it surprising. It also reverses an earlier decision. Layout state moves from per tag-on-output to per output.</p>
+<p>The last option is dwm's model (one client list, tags as a filter) with a tree in place of the list. The tree is the record of every relative position, permanently, because hidden windows never leave it. Nothing has to be restored. And for the planner, <strong>viewing or hiding any tag is always a single phase</strong>, because hidden windows are zero-weight seeds sitting at their own spot. Switching views never rearranges anything.</p>
+<p>Its cost is action at a distance. Intersperse A into tag 2's row below, then view tag 1 alone. A now sits under B and C, because in the tree it lives in the lower row. You changed tag 1's single view without ever viewing it alone.</p>
 <div class="demo" id="d8"></div>
 
-<h2>14. Decisions for you</h2>
-<div class="q"><strong>1. Direct or orthogonal style?</strong> Direct gives fewer phases and diagonal motion when it's safe. Orthogonal is the wry look, where every window moves along one axis at a time. It could be a config option, but the default shapes how monolith feels.</div>
-<div class="q"><strong>2. Rigid tag blocks?</strong> Should tags move as blocks when their order changes, and should the same apply to any container whose contents keep their arrangement? Blocks are calmer and need fewer lanes. Per-window planning is more uniform.</div>
-<div class="q"><strong>3. Lane extent.</strong> Lanes currently span only the band the involved windows occupy. Spanning the whole output gives thicker lanes for small windows, but disturbs more of the screen.</div>
-<div class="q"><strong>4. Seeds on edges instead of growing from the centre.</strong> Growing from the centre looks friendlier but overlaps the neighbours early on. Edge seeds never overlap. Centre growth drawn on top of everything is the alternative.</div>
-<div class="q"><strong>5. Pinch as the last resort.</strong> The alternative is a crossfade at the target, which is softer but means two copies of the window are visible at once.</div>
-<div class="q"><strong>6. One curve per motion group.</strong> This is forced by shared edges, but it means velocity matching follows the group's fastest mover. Slower windows in the group inherit its momentum. Acceptable?</div>
-<div class="q"><strong>7. One tree per output with tags as a filter</strong>, replacing per-tag layouts and the row-stacking merge rule (section 13)? If yes, what happens to a window's tree position when it is retagged? It can keep its spot, or move into the target tag's own row.</div>
-<div class="q"><strong>8. Floating windows</strong> are outside the no-overlap rule and move in one phase on top of the tiled layer. Should a floating-to-tiled transition join the plan as a seed, or keep floating above until it lands?</div>
+<h2>17. Decisions</h2>
+<h3>Settled</h3>
+<ul>
+  <li>Orthogonal is the default and the flagship look. Direct is a toggle.</li>
+  <li>Window moves and block moves both exist as commands. Tag reordering moves rigid blocks.</li>
+  <li>One curve per motion group, bounded by phase time rather than amount of motion.</li>
+  <li>Floating to tiled is phased, travel one axis per phase, then land.</li>
+  <li>The planner must never need a fallback. Pinch and lerp stay as safety nets to try.</li>
+</ul>
+<h3>Open</h3>
+<div class="q"><strong>Seed shape.</strong> Line on the old boundary, point on the old boundary, or target centre (section 4). Line is always one phase. Point looks more like your "grow from centre" but costs a phase in orthogonal style.</div>
+<div class="q"><strong>Landing in orthogonal style.</strong> The final "falls into place" step resizes both width and height at once. Is that an accepted exception, or must it also split into two phases?</div>
+<div class="q"><strong>Lane extent.</strong> Strips span only the band of the involved windows. Spanning the whole output gives thicker lanes for small windows, but disturbs more of the screen.</div>
+<div class="q"><strong>The layout model (section 16).</strong> One tree per output with tags as a filter, or something else. You raised the case of windows being closed and moved while others are hidden. In the one-tree model, hidden windows keep their slot, closing removes only that leaf, and moves are made relative to visible neighbours, so hidden siblings stay attached to whichever visible neighbour they were next to. That rule is what needs discussing.</div>
 </main>
 
 <script id="planner">
 const G = 10;
 const EPS = 0.5;
 let PHASE_MS = 450;
-let STYLE = 'direct';
+let STYLE = 'orthogonal';
 
 const R = (x, y, w, h) => ({ x, y, w, h });
 const clone = L => { const o = {}; for (const k in L) o[k] = { ...L[k] }; return o; };
@@ -220,6 +264,12 @@ function phaseOk(K1, K2, list) {
   return true;
 }
 function chg(a, b) { return { x: !(eq(a.x, b.x) && eq(a.w, b.w)), y: !(eq(a.y, b.y) && eq(a.h, b.h)) }; }
+function pureOk(keys) {
+  if (STYLE !== 'orthogonal') return true;
+  for (let k = 0; k + 1 < keys.length; k++)
+    for (const id in keys[k + 1]) { const c = chg(keys[k][id], keys[k + 1][id]); if (c.x && c.y) return false; }
+  return true;
+}
 
 function plan(from, to, opts = {}) {
   const list = Object.keys(to);
@@ -233,9 +283,54 @@ function plan(from, to, opts = {}) {
   const two = axisOrder(from, to, list, movers);
   if (two) return two;
   for (const ax of ['y', 'x']) { const l = lanes(from, to, list, movers, ax); if (l) return l; }
+  const g = grid(from, to, list, movers);
+  if (g) return g;
   return pinch(from, to, movers);
 }
 
+function conflictSet(from, to, list) {
+  const out = new Set();
+  for (let i = 0; i < list.length; i++)
+    for (let j = i + 1; j < list.length; j++) {
+      const a = list[i], b = list[j];
+      if ((relBits(from[a], from[b]) & relBits(to[a], to[b])) === 0) { out.add(a); out.add(b); }
+    }
+  return [...out];
+}
+
+function grid(from, to, list, movers) {
+  const cx = r => r.x + r.w / 2, cy = r => r.y + r.h / 2;
+  for (const set of [conflictSet(from, to, list), movers, list]) {
+    const n = set.length;
+    if (n < 2) continue;
+    let x0 = Infinity, x1 = -Infinity, y0 = Infinity, y1 = -Infinity;
+    for (const id of set) for (const r of [from[id], to[id]]) {
+      x0 = Math.min(x0, r.x); x1 = Math.max(x1, r.x + r.w); y0 = Math.min(y0, r.y); y1 = Math.max(y1, r.y + r.h);
+    }
+    const sh = (y1 - y0 - (n - 1) * G) / n, sw = (x1 - x0 - (n - 1) * G) / n;
+    const rowOf = {}, colOf = {};
+    [...set].sort((a, b) => cy(from[a]) - cy(from[b]) || cx(from[a]) - cx(from[b])).forEach((id, i) => rowOf[id] = y0 + i * (sh + G));
+    [...set].sort((a, b) => cx(to[a]) - cx(to[b]) || cy(to[a]) - cy(to[b])).forEach((id, i) => colOf[id] = x0 + i * (sw + G));
+    const inSet = new Set(set);
+    for (const phase of [3, 2, 4, 1]) {
+      const K = [{}, {}, {}];
+      for (const id of list) {
+        const f = from[id], t = to[id];
+        if (inSet.has(id)) {
+          K[0][id] = R(f.x, rowOf[id], f.w, sh);
+          K[1][id] = R(colOf[id], rowOf[id], sw, sh);
+          K[2][id] = R(colOf[id], t.y, sw, t.h);
+        } else for (let k = 0; k < 3; k++) K[k][id] = k + 1 >= phase ? t : f;
+      }
+      const keys = [from, ...K, to];
+      let ok = true;
+      for (let k = 0; k < 4 && ok; k++) ok = phaseOk(keys[k], keys[k + 1], list);
+      if (ok && pureOk(keys)) return { kind: `4 phases (${n}×${n} grid)`, keys, durs: [PHASE_MS, PHASE_MS, PHASE_MS, PHASE_MS] };
+    }
+  }
+  return null;
+}
+
 function mixed(f, t, xFirst) { return xFirst ? R(t.x, f.y, t.w, f.h) : R(f.x, t.y, f.w, t.h); }
 
 function axisOrder(from, to, list, movers) {
@@ -315,7 +410,7 @@ function lanes(from, to, list, movers, ax) {
           else if (phase === 2) { K1[id] = f; K2[id] = t; }
           else { K1[id] = f; K2[id] = f; }
         }
-        if (phaseOk(from, K1, list) && phaseOk(K1, K2, list) && phaseOk(K2, to, list))
+        if (phaseOk(from, K1, list) && phaseOk(K1, K2, list) && phaseOk(K2, to, list) && pureOk([from, K1, K2, to]))
           return { kind: `3 phases (${k} lanes)`, keys: [from, K1, K2, to], durs: [PHASE_MS, PHASE_MS, PHASE_MS] };
       }
     }
@@ -391,6 +486,7 @@ class Demo {
   constructor(id, W, H, opts = {}) {
     this.W = W; this.H = H;
     this.outputs = opts.outputs || [R(0, 0, W, H)];
+    this.floating = new Set(opts.floating || []);
     const el = document.getElementById(id);
     this.canvas = document.createElement('canvas');
     const dpr = window.devicePixelRatio || 1;
@@ -424,7 +520,7 @@ class Demo {
     const cur = this.sampleAt(now);
     const from = {};
     for (const id in target) from[id] = cur[id] || target[id];
-    const p = opts.blocks ? planBlocks(from, target, opts.blocks) : plan(from, target, { naive: this.naive });
+    const p = opts.planFn ? opts.planFn(from) : opts.blocks ? planBlocks(from, target, opts.blocks) : plan(from, target, { naive: this.naive });
     const curves = p.durs.map(() => BASE);
     const interrupted = !!this.anim;
     let matched = false;
@@ -485,7 +581,7 @@ class Demo {
     if (this.graph) this.drawGraph(now);
   }
   findOverlaps(L) {
-    const ids = Object.keys(L).filter(id => L[id].w > 0.5 && L[id].h > 0.5);
+    const ids = Object.keys(L).filter(id => L[id].w > 0.5 && L[id].h > 0.5 && !this.floating.has(id));
     const out = [];
     for (let i = 0; i < ids.length; i++) for (let j = i + 1; j < ids.length; j++) {
       const a = L[ids[i]], b = L[ids[j]];
@@ -503,7 +599,7 @@ class Demo {
       c.save();
       c.fillStyle = '#1b1e25'; c.fillRect(o.x, o.y, o.w, o.h);
       c.beginPath(); c.rect(o.x, o.y, o.w, o.h); c.clip();
-      for (const id in L) {
+      for (const id of Object.keys(L).sort((a, b) => this.floating.has(a) - this.floating.has(b))) {
         const r = L[id];
         if (r.w < 0.5 || r.h < 0.5) continue;
         const rad = Math.min(8, r.w / 2, r.h / 2);
@@ -549,10 +645,17 @@ const inner = (W, H, ox = 0) => R(ox + G, G, W - 2 * G, H - 2 * G);
 { // d2 one phase
   const W = 640, H = 300, d = new Demo('d2', W, H), I = inner(W, H);
   const s = { wide: false, d: false, e: false };
+  const modes = ['line on old boundary', 'point on old boundary', 'target centre'];
+  let mode = 0;
+  const ratios = ids => ids.map(id => (id === 'A' && s.wide) ? 2 : 1);
   const L = () => {
     const ids = s.d ? ['A', 'B', 'D', 'C'] : ['A', 'B', 'C'];
-    const out = splitX(I, ids, ids.map(id => (id === 'A' && s.wide) ? 2 : 1));
-    if (!s.d) out.D = R((out.B.x + out.B.w + out.C.x) / 2, I.y, 0, I.h);
+    const out = splitX(I, ids, ratios(ids));
+    if (!s.d) {
+      const bx = (out.B.x + out.B.w + out.C.x) / 2;
+      const T = splitX(I, ['A', 'B', 'D', 'C'], ratios(['A', 'B', 'D', 'C'])).D;
+      out.D = [R(bx, I.y, 0, I.h), R(bx, I.y + I.h / 2, 0, 0), R(T.x + T.w / 2, T.y + T.h / 2, 0, 0)][mode];
+    }
     const b = out.B;
     if (s.e) Object.assign(out, splitY(b, ['B', 'E'])); else out.E = R(b.x, b.y + b.h, b.w, 0);
     return out;
@@ -562,9 +665,12 @@ const inner = (W, H, ox = 0) => R(ox + G, G, W - 2 * G, H - 2 * G);
   d.button('Insert / remove D', () => { s.d = !s.d; d.go(L()); });
   d.button('Split B with E', () => { s.e = !s.e; d.go(L()); });
   d.button('All at once', () => { s.wide = !s.wide; s.d = !s.d; s.e = !s.e; d.go(L()); });
+  const mb = d.button('seed: ' + modes[0], () => {
+    mode = (mode + 1) % modes.length; mb.textContent = 'seed: ' + modes[mode];
+    if (!s.d && !d.anim) d.set(L());
+  });
   d.check('naive', false, v => d.naive = v);
 }
-
 function tagLayout(I, view2, order) {
   const L = {};
   if (view2) {
@@ -703,6 +809,78 @@ function anyVisible(node, visible) { return typeof node === 'string' ? visible(n
   d.button('Intersperse A between D and E', () => { mixed = !mixed; d.go(L()); });
 }
 
+function stackLayouts(I) {
+  const col = (L, id, ids) => { const r = L[id]; delete L[id]; Object.assign(L, splitY(r, ids)); return L; };
+  const row = (L, id, ids) => { const r = L[id]; delete L[id]; Object.assign(L, splitX(r, ids)); return L; };
+  return {
+    'A | B | C': () => splitX(I, ['A', 'B', 'C']),
+    'A | (B / C)': () => col(splitX(I, ['A', 'R']), 'R', ['B', 'C']),
+    '(A / C) | B': () => col(splitX(I, ['L', 'B']), 'L', ['A', 'C']),
+    '(A / B) | C': () => col(splitX(I, ['L', 'C']), 'L', ['A', 'B']),
+    'B | C | A': () => splitX(I, ['B', 'C', 'A']),
+    'A / B / C': () => splitY(I, ['A', 'B', 'C']),
+    'A / (B | C)': () => row(splitY(I, ['A', 'R']), 'R', ['B', 'C']),
+    '(A / B) | (C / D)': () => col(col(splitX(I, ['L', 'R']), 'L', ['A', 'B']), 'R', ['C', 'D']),
+    'A | (C / B / D)': () => col(splitX(I, ['A', 'R']), 'R', ['C', 'B', 'D']),
+    '(A / D) | (C / B)': () => col(col(splitX(I, ['L', 'R']), 'L', ['A', 'D']), 'R', ['C', 'B']),
+    '(A / B / C) | D': () => col(splitX(I, ['L', 'D']), 'L', ['A', 'B', 'C']),
+    '(A / C) | (B / D)': () => col(col(splitX(I, ['L', 'R']), 'L', ['A', 'C']), 'R', ['B', 'D']),
+  };
+}
+
+for (const [id, names] of [
+  ['d9a', ['A | B | C', 'A | (B / C)', '(A / C) | B', '(A / B) | C', 'B | C | A', 'A / B / C', 'A / (B | C)']],
+  ['d9b', ['(A / B) | (C / D)', 'A | (C / B / D)', '(A / D) | (C / B)', '(A / B / C) | D', '(A / C) | (B / D)']],
+]) {
+  const W = 640, H = 300, d = new Demo(id, W, H), I = inner(W, H), S = stackLayouts(I);
+  d.set(S[names[0]]());
+  for (const n of names) d.button(n, () => d.go(S[n]()));
+}
+
+{ // d9c grid
+  const W = 640, H = 300, d = new Demo('d9c', W, H), I = inner(W, H), S = stackLayouts(I);
+  let at = 0;
+  const names = ['(A / D) | (C / B)', '(A / B / C) | D'];
+  d.set(S[names[0]]());
+  d.button('(A / D) | (C / B)  ⇄  (A / B / C) | D', () => { at = 1 - at; d.go(S[names[at]]()); });
+}
+
+{ // d10 floating to tiled
+  const W = 640, H = 300, d = new Demo('d10', W, H, { floating: ['F'] }), I = inner(W, H);
+  const FL = R(220, 40, 220, 130);
+  let tiled = false;
+  const tiledL = () => splitX(I, ['A', 'B', 'F', 'C']);
+  const floatL = () => ({ ...splitX(I, ['A', 'B', 'C']), F: FL });
+  const ortho = () => STYLE === 'orthogonal';
+  const assemble = (n, tiledAt, fAt, kind) => {
+    const keys = [];
+    for (let i = 0; i <= n; i++) { const t = tiledAt(i); keys.push({ A: t.A, B: t.B, C: t.C, F: fAt(i) }); }
+    return { kind, keys, durs: keys.slice(1).map(() => PHASE_MS) };
+  };
+  const floatIn = from => {
+    const slot = tiledL().F, to = tiledL();
+    const bx = (from.B.x + from.B.w + from.C.x) / 2;
+    const tp = plan({ A: from.A, B: from.B, C: from.C, P: R(bx, I.y, 0, I.h) }, { A: to.A, B: to.B, C: to.C, P: slot });
+    const k = tp.durs.length, f = from.F;
+    const cx = slot.x + slot.w / 2 - f.w / 2, cy = slot.y + slot.h / 2 - f.h / 2;
+    const path = ortho() ? [f, R(cx, f.y, f.w, f.h), R(cx, cy, f.w, f.h)] : [f, R(cx, cy, f.w, f.h)];
+    const n = Math.max(path.length - 1, k) + 1;
+    return assemble(n, i => tp.keys[Math.min(i, k)], i => i === n ? slot : path[Math.min(i, path.length - 1)], `float in, slot ${tp.kind}`);
+  };
+  const floatOut = from => {
+    const slot = from.F, to = floatL();
+    const bx = (to.B.x + to.B.w + to.C.x) / 2;
+    const tp = plan({ A: from.A, B: from.B, C: from.C, P: slot }, { A: to.A, B: to.B, C: to.C, P: R(bx, I.y, 0, I.h) });
+    const k = tp.durs.length;
+    const lift = R(slot.x + slot.w / 2 - FL.w / 2, slot.y + slot.h / 2 - FL.h / 2, FL.w, FL.h);
+    const path = ortho() ? [slot, lift, R(lift.x, FL.y, FL.w, FL.h), FL] : [slot, lift, FL];
+    const n = Math.max(path.length - 1, k + 1);
+    return assemble(n, i => tp.keys[Math.max(0, Math.min(i - 1, k))], i => path[Math.min(i, path.length - 1)], `lift out, slot ${tp.kind}`);
+  };
+  d.set(floatL());
+  d.button('Tile F / float F', () => { tiled = !tiled; d.go(tiled ? tiledL() : floatL(), { planFn: tiled ? floatIn : floatOut }); });
+}
+
 document.getElementById('phaseMs').oninput = e => { PHASE_MS = +e.target.value; document.getElementById('phaseMsOut').textContent = PHASE_MS + ' ms'; };
 document.getElementById('style').onchange = e => { STYLE = e.target.value; };
 const loop = now => { for (const d of demos) d.frame(now); requestAnimationFrame(loop); };

monolith

Commit cd7085e54c88

Commit `cd7085e54c88`