rzen/lanework
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

The drag learns the stepper's trick — past the screen's edge, lane growth re-divides instead of stopping

Browse Source 
The right-edge drag's growth was capped at the screen's visible frame,
because each snap tick grows the window; on a window near the screen edge
that left a lane stuck at a tick or two of headroom. Settled 2026-08-08
(03-board-ui.md § Lane, superseding the pathfinder's hard stop): at the
screen the window pins and each further tick re-divides the fixed strip
width across one more unit — siblings compress, the stepper's mechanism
arriving under the drag's fingers. The regimes meet with no pixel jump
(the re-divided standard at the fit IS the frozen standard, by the
exact-fill identity), shrinking mirrors the way back, the rubber band
moves to the strip's own capacity, and a window with no headroom at all —
full screen included — re-divides from the very first snap.

New pure arithmetic in LaneLayoutMath (pinnedStripWidth, resizeStandard,
resizeMaxUnits, resizeWindowDelta, snappedUnits over per-count slots);
LaneResizeSession splits the tick across the regimes and derives its
standard from the live count; the handle and BoardView hand the session
the strip's whole divide. 2709 unit tests green (+11).

Claude-Session: https://claude.ai/code/session_014PtZdPwqZuqEDLc6wZMtEy
This commit is contained in:
rzen
2026-08-08 21:36:56 -04:00
parent 05b1a787de
commit 9a52b795b2
8 changed files with 564 additions and 91 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Kanban/UI/Board/LaneLayoutMath.swift
+159 -24
View File
@@ -16,10 +16,17 @@ import CoreGraphics
/// ported from the pathfinder's proven `ColumnResizeMath` (its reasoning is reproduced below,
/// since the behaviour is what was proven, not the code).
///
/// **The two mechanisms meet at the screen's visible frame** (settled 2026-08-08, § Lane): once the
/// window can grow no further the drag stops moving it and degrades to the re-divide — the same
/// fixed width across one more unit per tick, siblings compressing, which is precisely what the
/// stepper does. `pinnedStripWidth`, `resizeStandard`, `resizeMaxUnits` and `resizeWindowDelta` are
/// that second regime; they are written so the boundary itself costs no pixels, since the re-divided
/// standard at the screen fit *is* the frozen standard.
///
/// The one behavioural difference from the pathfinder: **Lanework has no upper width cap.** A lane
/// spans any whole number of units ≥ 1, so `allowedRange`'s ceiling is only ever the on-screen fit
/// (`maxUnits`) — there is no `Column.widthRange` equivalent to fold in, and shrinking is always
/// allowed.
/// spans any whole number of units ≥ 1, so `allowedRange`'s ceiling is not a width range but the
/// strip's own capacity (`resizeMaxUnits`) — there is no `Column.widthRange` equivalent to fold in,
/// and shrinking is always allowed.
enum LaneLayoutMath {
// MARK: - The resting layout
@@ -136,10 +143,37 @@ enum LaneLayoutMath {
/// 10pt (true of every lane width a real window produces), so calling this on every drag event
/// never oscillates.
///
/// Ticks are capped to `allowedRange`, which in Lanework folds in **only** the on-screen fit
/// (`maxUnits`) — there is no width cap to respect (03-board-ui.md § Lane: "1×, 2×, 3×, … — no
/// cap"), and the uncapped widths beyond the screen's capacity are the stepper's business, not
/// the drag's.
/// Ticks are capped to `allowedRange`, whose ceiling is the strip's capacity (`resizeMaxUnits`)
/// — there is no width cap to respect (03-board-ui.md § Lane: "1×, 2×, 3×, … — no cap"), and
/// past the screen fit the tick keeps firing, re-dividing rather than growing the window.
///
/// **`slotFor` rather than a standard**, because the standard is no longer one number for the
/// whole gesture: beyond the screen fit each further unit re-divides the pinned strip, so slot
/// `k` and slot `k + 1` are measured against *different* standards (`resizeStandard`). The
/// thresholds are unchanged in form — they simply ask the caller how wide each slot would be.
/// The band stays non-empty in the re-divide too: the slots still grow strictly with `k`, since
/// a unit added to a lane takes more from the strip than the re-divide gives back.
static func snappedUnits(
liveWidth: CGFloat,
currentUnits: Int,
slotFor: (Int) -> CGFloat,
gap: CGFloat,
allowedRange: ClosedRange<Int>,
reentry: CGFloat
) -> Int {
if currentUnits < allowedRange.upperBound, liveWidth > slotFor(currentUnits) + gap {
return currentUnits + 1
}
if currentUnits > allowedRange.lowerBound {
if liveWidth < slotFor(currentUnits - 1) + gap - reentry {
return currentUnits - 1
}
}
return currentUnits
}
/// The same snap where every slot is measured against one standard — the whole of the gesture
/// below the screen fit, and the shape the hit-testing and layout call sites think in.
static func snappedUnits(
liveWidth: CGFloat,
currentUnits: Int,
@@ -148,25 +182,21 @@ enum LaneLayoutMath {
allowedRange: ClosedRange<Int>,
reentry: CGFloat
) -> Int {
let currentSlot = slotWidth(units: currentUnits, standard: standard, gap: gap)
if currentUnits < allowedRange.upperBound, liveWidth > currentSlot + gap {
return currentUnits + 1
}
if currentUnits > allowedRange.lowerBound {
let previousSlot = slotWidth(units: currentUnits - 1, standard: standard, gap: gap)
if liveWidth < previousSlot + gap - reentry {
return currentUnits - 1
}
}
return currentUnits
snappedUnits(
liveWidth: liveWidth,
currentUnits: currentUnits,
slotFor: { slotWidth(units: $0, standard: standard, gap: gap) },
gap: gap,
allowedRange: allowedRange,
reentry: reentry)
}
/// The live width rubber-banded to stay near the allowed slot range: inside `[minSlot,
/// maxSlot]` the proposed width passes through untouched; beyond either end only `resistance`
/// (0.25) of the overshoot is applied, so the edge visibly resists but still gives, signalling
/// the bound without a hard stop (03-board-ui.md § Lane: "Growth hard-stops at the screen's
/// visible frame, with rubber-band feedback"). The snap tick never follows the width past the
/// bound (see `snappedUnits`' clamp), so this is purely cosmetic give.
/// the bound without a hard stop (03-board-ui.md § Lane: the rubber band "moves to the true end
/// of travel — the strip's own capacity"). The snap tick never follows the width past the bound
/// (see `snappedUnits`' clamp), so this is purely cosmetic give.
static func resistedWidth(
proposed: CGFloat,
minSlot: CGFloat,
@@ -184,9 +214,12 @@ enum LaneLayoutMath {
/// allowed regardless of screen room, including from a window already hanging off the edge
/// (negative headroom).
///
/// Unlike the pathfinder's twin there is no width ceiling to `min` against: the drag's only
/// bound is the screen, because it is the mechanism that grows the window. Larger widths are
/// reachable through the stepper, which re-divides instead (03-board-ui.md § Lane).
/// Unlike the pathfinder's twin this is **not the tick's ceiling** — it is the boundary where
/// one mechanism hands over to the other (settled 2026-08-08, 03-board-ui.md § Lane). Up to it
/// the drag grows the window and the siblings keep their pixels; past it the window is spent and
/// each further tick re-divides instead (`resizeStandard`), which is how a lane keeps growing at
/// the siblings' expense on a full screen. A window with no headroom at all answers
/// `currentUnits`, so the very first tick is already a re-divide.
///
/// Pure so it can be unit-tested; the session computes `headroom` from the live window and its
/// screen and defers the arithmetic here.
@@ -195,4 +228,106 @@ enum LaneLayoutMath {
let extra = Int(floor(max(0, min(headroom, CGFloat(Int.max) / 2)) / step))
return max(currentUnits, currentUnits + extra)
}
// MARK: - The drag past the screen: the re-divide
/// The strip's width once the window has grown as far as its screen allows — the width every
/// tick past the screen fit re-divides, since the window is pinned from there on.
///
/// The drag-start width is **derived, not measured**: the strip always fills exactly
/// (`standardWidth`), so a frozen standard `s` over `T` units means a strip of `s·T + g·(T + 1)`
/// and nothing else. Growth adds one `s + g` step per unit of on-screen headroom. Deriving it is
/// what makes the boundary free: a measured viewport width, carrying whatever half-point the
/// layout rounded to, would put a visible step where the two regimes meet.
static func pinnedStripWidth(
startUnits: Int,
startStandard: CGFloat,
startTotalUnits: Int,
fittingUnits: Int,
gap: CGFloat
) -> CGFloat {
let total = CGFloat(max(1, startTotalUnits))
let atStart = startStandard * total + gap * (total + 1)
return atStart + CGFloat(max(0, fittingUnits - startUnits)) * (startStandard + gap)
}
/// The strip's standard (1×) width part-way through a right-edge drag, for a dragged lane
/// spanning `units` — the whole of the drag's two regimes in one function (03-board-ui.md
/// § Lane, settled 2026-08-08).
///
/// At or below the screen fit the answer is the standard frozen at drag start: the window takes
/// the step, so the division is unchanged and every other lane keeps its exact pixels. Past the
/// fit the window is pinned, so each further unit the dragged lane claims is one more unit the
/// same `pinnedStripWidth` has to divide across — the siblings compress, which is the stepper's
/// mechanism arriving under the drag's fingers.
///
/// **The regimes meet with no pixel jump.** At `units == fittingUnits` the pinned width divided
/// across its own unit total is `startStandard` exactly, by the exact-fill identity
/// `pinnedStripWidth` is built from — the same reason the release hands back to the resting
/// layout without a flinch (`LaneResizeSession`).
static func resizeStandard(
forUnits units: Int,
startUnits: Int,
startStandard: CGFloat,
startTotalUnits: Int,
fittingUnits: Int,
gap: CGFloat
) -> CGFloat {
guard units > fittingUnits else { return startStandard }
return standardWidth(
stripWidth: pinnedStripWidth(
startUnits: startUnits, startStandard: startStandard,
startTotalUnits: startTotalUnits, fittingUnits: fittingUnits, gap: gap),
totalUnits: max(1, startTotalUnits) + (units - startUnits),
gap: gap)
}
/// The drag's ceiling — the true end of travel, which past the screen fit is a question about
/// the strip's capacity rather than about the screen.
///
/// The re-divide can always take one more unit, but not usefully forever: at some total
/// `standardWidth`'s 1pt floor engages and the strip stops filling exactly, which is the point
/// where the arithmetic stops describing anything on screen. That total is the largest `T`
/// satisfying `(W − g·(T + 1)) / T ≥ 1`, i.e. `floor((W − g) / (1 + g))`, and the dragged lane's
/// ceiling is that total read back through the units it contributed. This is where the rubber
/// band now sits (§ Lane: "the true end of travel — the strip's own capacity").
///
/// **Never below the screen fit**, and so never below the count the drag started from —
/// shrinking is always allowed. A degenerate strip (a non-finite standard, a gap at or below
/// −1pt, a capacity under one whole unit) falls back to the fit rather than inventing a bound.
static func resizeMaxUnits(
startUnits: Int,
startStandard: CGFloat,
startTotalUnits: Int,
fittingUnits: Int,
gap: CGFloat
) -> Int {
let fit = max(startUnits, fittingUnits)
guard startStandard.isFinite, gap.isFinite, gap > -1 else { return fit }
let width = pinnedStripWidth(
startUnits: startUnits, startStandard: startStandard,
startTotalUnits: startTotalUnits, fittingUnits: fittingUnits, gap: gap)
guard width.isFinite else { return fit }
let capacity = (width - gap) / (1 + gap)
guard capacity >= 1 else { return fit }
let total = Int(min(capacity, CGFloat(Int.max) / 2).rounded(.down))
return max(fit, startUnits + (total - max(1, startTotalUnits)))
}
/// How far the window moves on a tick from `oldUnits` to `newUnits`: one `step` per unit of that
/// change lying **inside** the screen fit, and nothing at all for the part beyond it, where the
/// re-divide has taken over and the window is pinned (03-board-ui.md § Lane).
///
/// A difference of clamped counts rather than a per-step walk, because a flick can cross the
/// boundary in one gesture event and the two sides must net out exactly: `F − 1 → F + 2` is one
/// step (only the first unit was ever the window's to give), `F + 2 → F + 5` is none, and
/// `F + 2 → F − 1` hands that one step back. Shrinking mirrors growing by construction.
static func resizeWindowDelta(
from oldUnits: Int,
to newUnits: Int,
fittingUnits: Int,
step: CGFloat
) -> CGFloat {
CGFloat(min(newUnits, fittingUnits) - min(oldUnits, fittingUnits)) * step
}
}