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

The empty provider was never load-bearing — the dragless layer frees the rubber band

Browse Source 
Measured on real events 2026-08-07, correcting the 2026-08-06 hosted
finding: a bare count-1 tap on LaneView's empty-space layer fires in
~1-3 ms with no drag source at all — the hold that made the empty
.onDrag look necessary was the sterile NSApp.postEvent stream
over-disambiguating. And the provider was actively harmful: even an
empty drag source claims the mouse-drag at threshold, starving the
marquee's simultaneous DragGesture after one sample — the band froze
and the mouseUp never arrived. The layer goes dragless; drags from
empty space belong wholly to MarqueeControl. PointerClick's and the
layer's comments retell the corrected story. Alongside: openCard is
typed @MainActor throughout, which makes the closure Sendable and
lets CardFaceRole carry it under CardFaceView's nonisolated ==.

Claude-Session: https://claude.ai/code/session_014PtZdPwqZuqEDLc6wZMtEy
This commit is contained in:
rzen
2026-08-07 12:55:54 -04:00
parent b0ffff1aa1
commit 8aefaf23ce
9 changed files with 42 additions and 36 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Kanban/UI/Board/BoardCommands.swift
+1 -1
View File
@@ -41,7 +41,7 @@ final class CardOpener {
/// `nil` until the window's board has loaded, which is also exactly when Open Card has nothing
/// to act on.
var open: ((ItemID) -> Void)?
var open: (@MainActor (ItemID) -> Void)?
init() {}
}
Kanban/UI/Board/BoardView.swift
+1 -1
View File
@@ -67,7 +67,7 @@ struct BoardView: View {
/// Opens a card's window — ⌘↩'s second half (04-interactions.md ▸ Grammar). A closure from
/// `BoardWindowHost` rather than an `openWindow` call here, because building a `CardWindowRef`
/// needs the board's own window ref, which is the host's identity and not the board's.
let openCard: (ItemID) -> Void
let openCard: @MainActor (ItemID) -> Void
/// The toolbar search field's handle (`BoardSearchPresentation`), threaded down so the strip can
/// fill in `focusBoard` — Escape's "in an empty field it returns focus to the board" needs the
Kanban/UI/Board/CardFaceView.swift
+5 -2
View File
@@ -30,11 +30,14 @@ import SwiftUI
/// **Only the trash side carries the confirmation host** (settled): the board side's Delete is the
/// ordinary staged move into `.trash/` and never stands an alert, so `board` needs nothing beyond the
/// card opener.
enum CardFaceRole {
/// `Sendable` because `CardFaceView.==` is nonisolated and a nonisolated context may only read a
/// main-actor `let` of Sendable type — which is why `openCard` is typed `@MainActor` (an isolated
/// function type is Sendable; a bare one is not, and would sink the whole enum).
enum CardFaceRole: Sendable {
/// A card in a lane. Carries the board window's card opener — ⌘↩'s pointer twin
/// (04-interactions.md ▸ Selection).
case board(openCard: (ItemID) -> Void)
case board(openCard: @MainActor (ItemID) -> Void)
/// A card in `<root>/.trash/`. Carries the window's purge-alert host, because the trash's Delete
/// is the permanent one and "confirms exactly where the loss is real" (03 § Trash).
Kanban/UI/Board/LaneView.swift
+19 -19
View File
@@ -71,7 +71,7 @@ struct LaneView: View, Equatable {
/// Opens a card's window — ⌘↩'s second half (04-interactions.md ▸ Grammar, "commits and opens
/// the card window"). Supplied by the strip, which is supplied by the host: a lane has no
/// business knowing about `WindowGroup` keys.
let openCard: (ItemID) -> Void
let openCard: @MainActor (ItemID) -> Void
/// Reduce Motion, for the card transition below (10-accessibility.md). Read from the environment
/// and handed to `Motion`, which owns what "reduced" means.
@@ -844,26 +844,26 @@ struct LaneView: View, Equatable {
Rectangle()
.fill(.clear)
.contentShape(Rectangle())
// **The empty provider is load-bearing, and it is not a drag** (measured,
// 2026-08-06): without a drag source on this layer, macOS holds its primary
// clicks pending multi-click disambiguation — a lone click on lane empty
// space simply never fired its tap on the hosted board, drag source absent,
// and fired in ~90 ms with one present. The card faces, the lane header and
// the trash rows are instant for exactly this reason: their real `.onDrag`
// forces immediate event delivery for the whole subtree. An **empty**
// provider keeps that delivery guarantee while refusing every actual drag
// before a session starts (`CardAttachmentsSection`'s gone-file idiom), so
// dragging from empty space still belongs wholly to the rubber band's
// simultaneous `DragGesture` on the container — whose begin guard already
// expects to sample drags it must decline (`MarqueeControl`).
.onDrag { NSItemProvider() }
// **No drag source on this layer, deliberately** (measured on real events,
// 2026-08-07): an `.onDrag` here — even one whose provider is empty — claims
// the mouse-drag the moment the cursor crosses the drag threshold, and the
// rubber band's simultaneous `DragGesture` on the container gets one sample
// and then silence: the band begins and freezes, and even the mouseUp never
// reaches the app. Dragless, the same sweep tracks every sample. And the drag
// source buys nothing in return: a bare count-1 tap on this layer fires in
// ~1–3 ms in a real event stream, identical to the with-`.onDrag` shape — the
// hold that made an empty provider look load-bearing (2026-08-06, "a lone
// click never fired") was the hosted harness's sterile `NSApp.postEvent`
// stream, which over-holds; real streams have nothing to disambiguate here.
// So: drags from empty space belong wholly to the band (`MarqueeControl`),
// whose begin guard keeps card-face drags out by geometry.
// **One recogniser, both meanings** — a single `.onTapGesture` that branches
// on `PointerClick.count`, AppKit's own `mouseDown` idiom. Not a second
// two-tap recogniser in *either* form: sequential stacking is the bug this
// fix removes, and even a simultaneous `TapGesture(count: 2)` makes macOS
// hold this layer's primary clicks for the whole double-click interval,
// because the layer — unlike the card faces, the header and the trash rows —
// carries no `.onDrag` to force immediate delivery (see `PointerClick`).
// fix removes, and a *multi-click* recogniser — sequential or simultaneous —
// is what makes macOS hold a dragless subtree's primary clicks for the whole
// double-click interval (see `PointerClick`; the count-1 tap alone triggers
// no such hold).
// A lone tap fires once; a double fires it once per click, so the branch is
// Finder's cadence exactly: the first click selects, the second creates.
//
@@ -1256,7 +1256,7 @@ private struct NewCardStubView: View {
/// the face this view draws and the identity the slot is keyed by are the same answer.
let phase: NewCardPlaceholder.Phase
let openCard: (ItemID) -> Void
let openCard: @MainActor (ItemID) -> Void
/// Increase Contrast, for the editor well's stroke below (10-accessibility.md; `Accommodations`).
@Environment(\.colorSchemeContrast) private var contrast
Kanban/UI/Board/SelectionClicks.swift
+12 -9
View File
@@ -31,15 +31,18 @@ extension ClickModifier {
/// SwiftUI's `TapGesture` hands its handler nothing about the event.
///
/// **This is how a surface without a drag source gets a double-click meaning** (the 2026-08-06
/// click-latency fix). A second tap recogniser is never the way: a sequential
/// `.onTapGesture(count: 2)` makes every single click on its subtree wait out the system
/// double-click interval — and on macOS even a *simultaneous* two-tap recogniser holds primary
/// clicks on views that carry no `.onDrag`. (A drag source forces immediate event delivery, which
/// is why the card faces, the lane header and the trash rows — `CardFaceView`'s simultaneous
/// arrangement — stay instant; `LaneView`'s empty-space layer measurably does not.) A single
/// `.onTapGesture` fires once per click of a run, so branching on this count expresses
/// "first click selects, second creates" — Finder's cadence — with exactly one recogniser and
/// nothing to disambiguate.
/// click-latency fix). A second tap recogniser is never the way: a *multi-click* recogniser on a
/// dragless subtree — a sequential `.onTapGesture(count: 2)` or even a simultaneous two-tap —
/// makes macOS hold every primary click on that subtree pending disambiguation for the system
/// double-click interval. (A real `.onDrag` forces immediate delivery, which is why the card
/// faces, the lane header and the trash rows — `CardFaceView`'s simultaneous arrangement — can
/// carry one and stay instant. A lone count-1 tap needs no such help: measured on real events
/// 2026-08-07, `LaneView`'s dragless empty-space layer fires in ~1–3 ms — there is nothing to
/// disambiguate. And an `.onDrag` must never be added there *for* delivery: even an
/// empty-provider drag source claims drags outright and kills the rubber band's simultaneous
/// `DragGesture`.) A single `.onTapGesture` fires once per click of a run, so branching on this
/// count expresses "first click selects, second creates" — Finder's cadence — with exactly one
/// recogniser and nothing to disambiguate.
enum PointerClick {
/// The `clickCount` of the click being handled: 1 for a lone click or a run's first, 2 for