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

Land Finder file drops positionally, header release topmost

Browse Source 
04's settled clauses were mostly shipped already — the create landing
resolved through DropSlotMath.cardSlot with one nominal shadow per
importable file — but a release on the lane header fell through to the
card zones, which clamp inward, so a scrolled lane could propose behind
the header stripe. FileDropZones now folds header, attach hit-test, and
card-slot resolution into one pure seam asked in that order, the header
answering topmost per the ruling; lane headers register their frames
for it. FinderDrop.shadowCount names the floor-at-one rule. New tests
pin the header boundary, a differential against cardSlot's own zones
(same zones, not similar), and a store-level differential proving a
file landing takes the very ranks a card move there takes.

Claude-Session: https://claude.ai/code/session_01SR4XGjmBE16ZUYWpfFHXwY
This commit is contained in:
rzen
2026-07-28 08:28:28 -04:00
parent 7be9bb2345
commit 524488122f
7 changed files with 392 additions and 72 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Kanban/LiveStore/BoardStore.swift
+8 -1
View File
@@ -1704,7 +1704,14 @@ public final class BoardStore {
}
/// Creates one card per file at `index` in `laneID`, each titled with its filename minus the
/// extension and carrying that file as its attachment — the drop-on-empty-space half.
/// extension and carrying that file as its attachment — the drop-into-a-lane half.
///
/// **`index` is the drop position, not the lane's end** (04-interactions.md ▸ Drag and drop,
/// settled 2026-07-28): "created cards land at the drop position — resolved through the same
/// card-grid zones an ordinary card drag uses … drops are positional everywhere, and
/// append-at-bottom stays the creation *trio*'s rule, not the drop's". The gesture resolves it
/// through `FileDropZones.landing`; the rank arithmetic below is `moveCards`', so a run landing
/// between two siblings takes exactly the ranks a card drop there would have produced.
///
/// **Ordinary store writes, with no drop-only path**: a fresh GUID and an inserted rank per card
/// (`Ranks.insertionRanks`, compacting and placing again when midpoint precision is exhausted,
Kanban/UI/Board/BoardDrops.swift
+72 -55
View File
@@ -4,8 +4,8 @@ import UniformTypeIdentifiers
// MARK: - What each lane draws, as the drag reads it
/// Where each lane's card grid is drawn and how tall its cards are — the measured half of the card
/// masonry's drop geometry, one registry per board window.
/// Where each lane's card grid and title bar are drawn and how tall its cards are — the measured
/// half of the card masonry's drop geometry, one registry per board window.
///
/// **Deliberately not `@Observable`.** Nothing renders off it: it exists so a drop delegate and the
/// autoscroll driver can ask, at *event* time, where the grid is and what the resting row extents
@@ -25,6 +25,10 @@ import UniformTypeIdentifiers
/// are never measured: they are replayed analytically from these heights through
/// `MasonryPlacement.frames(heights:)`, which is the very function `MasonryLayout` places with
/// (DRAG-REORDER.md § The card masonry).
/// - **Each lane's header frame.** The title bar sits outside the card scroll view and above it, so
/// it neither scrolls nor reflows for anything a drop can do; it is read for one rule only — "a
/// release on the lane header resolves to the topmost position" (04-interactions.md ▸ Drag and
/// drop, settled 2026-07-28), which needs an edge the scrolling masonry cannot supply.
///
/// The one input that *is* frozen at drag start is the **dragged** cards' own heights, which live on
/// `DragSession`: the pickup transition scales the replica and corrupts its last measured frame.
@@ -54,9 +58,17 @@ final class LaneDropRegistry {
private(set) var grids: [ItemID: Grid] = [:]
private(set) var heights: [ItemID: CGFloat] = [:]
/// Each lane's title bar, in the same global space `Grid.frame` is written in — the topmost-rule
/// stripe (`FileDropZones.landing`). Absent for a lane that has not laid its header out yet, and
/// the file zones then let the masonry answer alone.
private(set) var headers: [ItemID: CGRect] = [:]
func update(_ grid: Grid, for laneID: ItemID) { grids[laneID] = grid }
func removeGrid(_ laneID: ItemID) { grids.removeValue(forKey: laneID) }
func update(header frame: CGRect, for laneID: ItemID) { headers[laneID] = frame }
func removeHeader(_ laneID: ItemID) { headers.removeValue(forKey: laneID) }
func update(height: CGFloat, for cardID: ItemID) { heights[cardID] = height }
func removeHeight(_ cardID: ItemID) { heights.removeValue(forKey: cardID) }
}
@@ -303,40 +315,27 @@ struct BoardDropContext {
acceptsFileDrops && FinderDrop.importableCount(info.itemProviders(for: [.fileURL])) > 0
}
/// How many **files** the session carries — the shadow run's length on the create path, and the
/// count the create path is sized by: folders are not imported, so they draw no shadow and mint
/// no card (the refusal rule above).
///
/// Read from `info` on every sample rather than captured at `dropEntered`: a delegate can be
/// entered without this window ever having seen the enter callback (single-target dispatch hands
/// the session to whichever region is deepest), and a count that was never set would draw the
/// wrong number of shadows.
private func fileCount(_ info: DropInfo) -> Int {
max(1, FinderDrop.importableCount(info.itemProviders(for: [.fileURL])))
}
/// Where a **file** session would land in `laneID` — the file mode's twin of `retargetCards`,
/// resolved against the very same analytic masonry geometry.
///
/// Two answers, in this order:
/// The three answers and the order they are asked in are `FileDropZones.landing`'s, kept there so
/// the ruling is checkable without a window; this is the adapter that feeds it the snapshot and
/// the registry and turns its answer into a proposal. In short: the **header** is the topmost
/// position, a **card under the cursor** attaches, and everything else is the **create slot** the
/// ordinary card zones produce.
///
/// 1. **A card under the cursor always wins** (04-interactions.md ▸ Drag and drop): attach beats
/// create, anywhere on the card's bounds. The bounds are the resting frames
/// `MasonryPlacement.frames(heights:)` replays — the same reconstruction the card-slot zones
/// are built from, never a measured frame (03-board-ui.md § Motion). While a create shadow is
/// open the *drawn* cards sit lower than their resting frames, which is exactly the tradeoff
/// every proposal in this app makes: the answer stays a pure function of the cursor and the
/// snapshot, so it cannot oscillate — the drawn layout never feeds back into it.
/// 2. **Otherwise the create slot**, from `DropSlotMath.cardSlot` — "new cards land at the drop
/// position using the same card-grid zone math ordinary card drags use". The footprint the
/// span cap is measured against is the nominal card height, since the cards being proposed do
/// not exist yet to have one; the cap only ever truncates a zone that lies *over* an existing
/// card, and that region is case 1's.
/// **Created cards land at the drop position** (04-interactions.md ▸ Drag and drop, settled
/// 2026-07-28): "resolved through the same card-grid zones an ordinary card drag uses, shadow
/// included — drops are positional everywhere, and append-at-bottom stays the creation *trio*'s
/// rule, not the drop's."
///
/// **Positional landing is filed for design ratification.** 04's bullet says only "dropped on
/// lane empty space → creates a card"; that the card lands at the *drop position* rather than at
/// the lane's bottom is this milestone's reading of the pathfinder's `retargetFile` precedent,
/// implemented here and awaiting the design's word.
/// **The landing shadow is the create path's whole feedback** (settled, same bullet): no lane-level
/// highlight is proposed here or drawn anywhere, because "each target gets one clear signal, and
/// the card-attach highlight exists precisely because that target has no shadow".
///
/// While a create shadow is open the *drawn* cards sit lower than their resting frames, which is
/// exactly the tradeoff every proposal in this app makes: the answer stays a pure function of the
/// cursor and the snapshot, so it cannot oscillate — the drawn layout never feeds back into it.
func retargetFile(inLane laneID: ItemID, info: DropInfo) {
guard acceptsFileDrop(info), let cursor = globalCursor(),
let lane = store.snapshot.lanes.first(where: { $0.id == laneID && !$0.isDeleted }),
@@ -355,36 +354,34 @@ struct BoardDropContext {
spacing: grid.spacing,
origin: grid.frame.origin
)
let count = fileCount(info)
let count = FinderDrop.shadowCount(info.itemProviders(for: [.fileURL]))
// Closed containment — a cursor sitting exactly on a shared edge still counts, and the first
// match wins, so the answer is deterministic however the frames abut.
let frames = placement.frames(heights: heights)
if let index = frames.firstIndex(where: { frame in
cursor.x >= frame.minX && cursor.x <= frame.maxX
&& cursor.y >= frame.minY && cursor.y <= frame.maxY
}), index < rendered.count {
let landing = FileDropZones.landing(
cursor: cursor,
headerBottom: registry.headers[laneID]?.maxY,
placement: placement,
heights: heights,
nominalHeight: LaneDropRegistry.nominalCardHeight,
current: session.fileLaneProposal(onBoardRooted: store.rootURL, laneID: laneID)?.index
)
switch landing {
case .hold:
return // a dead region: hold whatever the create slot already was
case let .attach(index):
guard rendered.indices.contains(index) else { return }
session.proposeFile(FileDropTarget(
boardRoot: store.rootURL,
landing: .attach(cardID: rendered[index].id),
fileCount: count
))
return
case let .create(index):
session.proposeFile(FileDropTarget(
boardRoot: store.rootURL,
landing: .create(laneID: laneID, index: index),
fileCount: count
))
}
let slot = DropSlotMath.cardSlot(
cursor: cursor,
placement: placement,
heights: heights,
draggedHeight: LaneDropRegistry.nominalCardHeight,
current: session.fileLaneProposal(onBoardRooted: store.rootURL, laneID: laneID)?.index
)
guard let slot else { return } // a dead region: hold whatever the create slot already was
session.proposeFile(FileDropTarget(
boardRoot: store.rootURL,
landing: .create(laneID: laneID, index: slot),
fileCount: count
))
}
/// The strip's fall-through for file sessions: which lane is under the cursor, analytically.
@@ -705,6 +702,23 @@ enum FinderDrop {
providers.filter { !isDirectory(typeIdentifiers: $0.registeredTypeIdentifiers) }.count
}
/// How many shadows the create path draws — **one nominal-height shadow per incoming file**
/// (04-interactions.md ▸ Drag and drop, settled 2026-07-28: the multi-drag precedent), **floored
/// at one**: "when macOS withholds item counts during hover the count floors at one shadow, the
/// commit unaffected".
///
/// The floor is a *hover* concession and nothing more. A drag whose providers cannot be counted
/// still opens a slot the user can aim at, and the write is `FinderDrop.land`'s — resolved URLs,
/// partitioned against the filesystem — so one shadow standing in for three files costs the drop
/// nothing. It is read from the drag on every sample rather than captured at `dropEntered`: a
/// delegate can be entered without this window ever having seen the enter callback (single-target
/// dispatch hands the session to whichever region is deepest), and a count that was never set
/// would draw the wrong number of shadows.
@MainActor
static func shadowCount(_ providers: [NSItemProvider]) -> Int {
max(1, importableCount(providers))
}
// MARK: The drop read — the filesystem
/// Whether `url` is a directory, as the filesystem answers it — the authoritative read.
@@ -807,7 +821,10 @@ let boardDropTypes: [UTType] = boardDragTypes + [.fileURL]
/// **Card sessions** resolve against this lane's masonry zones. **Lane sessions** are forwarded to
/// the strip's logic (cursor converted to strip space by the shared context), so lane reordering
/// keeps working while the cursor crosses lane bodies. **File sessions** resolve against those same
/// masonry zones — onto a card they become attachments, onto empty space one card per file.
/// masonry zones — onto a card they become attachments, onto the grid one card per file at the drop
/// position, and onto the **header** the topmost position, since the target is the whole lane body
/// and a dead stripe across its top would be the one place a file drop refused for no reason
/// (04-interactions.md ▸ Drag and drop, settled 2026-07-28).
struct LaneDropDelegate: DropDelegate {
let context: BoardDropContext
Kanban/UI/Board/DragSession.swift
+27 -6
View File
@@ -109,9 +109,18 @@ struct FileDropTarget: Equatable, Sendable {
enum Landing: Equatable, Sendable {
/// **Onto a card**: the files copy into that card's `attachments/`. A card under the cursor
/// always wins over the lane behind it — attach beats create, anywhere on the card's bounds.
/// This is the one file landing that **highlights**, and only because it has no shadow to
/// show instead (04-interactions.md ▸ Drag and drop, settled 2026-07-28).
case attach(cardID: ItemID)
/// **Onto lane empty space**: one card per file, landing at this position in the lane's
/// **Onto the lane's card grid**: one card per file, landing at this position in the lane's
/// logical card order.
///
/// **Positional, everywhere the grid reaches** (04-interactions.md ▸ Drag and drop, settled
/// 2026-07-28): "created cards land at the drop position — resolved through the same
/// card-grid zones an ordinary card drag uses, shadow included", and a release on the lane
/// **header** resolves to index 0, the topmost position. Append-at-bottom is the creation
/// trio's rule (⌘N, Return, a double click), never the drop's. `FileDropZones.landing` is
/// where the index comes from.
case create(laneID: ItemID, index: Int)
}
@@ -121,12 +130,15 @@ struct FileDropTarget: Equatable, Sendable {
var landing: Landing
/// How many files ride along — the create path's shadow run length, one shadow per card that
/// will land. Read off the session's item providers at hover time, floored at one.
/// How many files ride along — **one nominal-height shadow per incoming file** on the create path
/// (04-interactions.md ▸ Drag and drop, settled 2026-07-28: the multi-drag precedent), one shadow
/// per card that will land. Read off the session's item providers at hover time
/// (`FinderDrop.shadowCount`), **floored at one** for the drag whose count macOS withholds — the
/// commit is unaffected either way, since the write counts resolved URLs, not providers.
///
/// **Folders are not counted** (04-interactions.md ▸ Drag and drop: "a mixed drag proposes for
/// its files only"): `FinderDrop.importableCount` reads the providers' declared types, so a
/// mixed drag draws shadows for its files alone and a folders-only drag never proposes at all.
/// **Folders are not counted** (same bullet: "a mixed drag proposes for its files only"):
/// `FinderDrop.importableCount` reads the providers' declared types, so a mixed drag draws
/// shadows for its files alone and a folders-only drag never proposes at all.
var fileCount: Int
}
@@ -568,6 +580,15 @@ final class DragSession {
/// The shadow run a file drop would open in `laneID` on this board — where the created cards
/// land and how many there are — or `nil` when the proposal is elsewhere.
///
/// **This run is the create path's whole feedback** (04-interactions.md ▸ Drag and drop, settled
/// 2026-07-28): there is no lane-level highlight to go with it, deliberately — each target gets
/// one clear signal, and `fileAttachTarget` above is the highlight precisely because a card
/// target has no shadow.
///
/// The floor restates `FinderDrop.shadowCount`'s, at the render end rather than in place of it: a
/// proposal that somehow carried a zero would otherwise open a run of no shadows at all, which is
/// a landing spot the user cannot see.
func fileLaneProposal(onBoardRooted root: URL, laneID: ItemID) -> (index: Int, count: Int)? {
guard let fileTarget,
DragLocality.isSameBoard(fileTarget.boardRoot, root),
Kanban/UI/Board/DropSlotMath.swift
+82
View File
@@ -285,3 +285,85 @@ enum DropSlotMath {
return remaining
}
}
// MARK: - A Finder file drag's zones
/// Where an external **Finder file** drag resolves inside one lane, as pure arithmetic
/// (`FileDropZoneTests`) — the three answers a lane's own geometry gives it.
///
/// **Drops are positional everywhere** (04-interactions.md ▸ Drag and drop, settled 2026-07-28):
/// "created cards land at the drop position — resolved through the same card-grid zones an ordinary
/// card drag uses, shadow included", and append-at-bottom stays the creation *trio*'s rule (⌘N,
/// Return, a double click on empty space), not the drop's. So the create landing is
/// `DropSlotMath.cardSlot` and nothing else: the very function a card drag proposes through, with the
/// incoming run's **nominal** footprint standing in for the frozen height a card drag freezes at
/// pickup — the cards being proposed do not exist yet to have been measured, exactly as a cross-board
/// arrival's do not.
///
/// Kept out of `BoardDropContext` for `TrashDrop`'s reason: the ruling is then checkable without a
/// window, and the hover and the release read one answer rather than two that can drift.
enum FileDropZones {
/// What the lane's geometry says the files would become.
enum Landing: Equatable, Sendable {
/// The cursor is over the card at this position in the lane's **logical** card order — the
/// files join its `attachments/`. Attach beats create anywhere on a card's bounds.
case attach(index: Int)
/// One card per file, opening at this position in the logical card order.
case create(index: Int)
/// A dead region (`DropSlotMath.slot`'s `nil`): **hold** whatever the create slot already was.
case hold
}
/// Resolves `cursor` against one lane, in three questions asked in this order.
///
/// 1. **The lane header is the topmost position** (04-interactions.md ▸ Drag and drop, settled
/// 2026-07-28: "a release on the lane header resolves to the topmost position — forgiving beats
/// a dead stripe: the header's chrome roles don't collide with a file payload"). The header
/// does not scroll, so its own edge is the honest boundary; the accent band and the plate's top
/// padding sit above it and are its chrome, which is why the test is *at or above* rather than
/// containment. It is asked **first** because a scrolled masonry can place a card's analytic
/// frame behind the header stripe, and the ruling admits no exception there.
/// 2. **A card under the cursor always wins** over the lane behind it. The bounds are the resting
/// frames `MasonryPlacement.frames(heights:)` replays — the same reconstruction the slot zones
/// are built from, never a measured frame (03-board-ui.md § Motion). Closed containment, first
/// match wins, so the answer is deterministic however the frames abut.
/// 3. **Otherwise the create slot**, from `DropSlotMath.cardSlot`.
///
/// - Parameters:
/// - cursor: the pointer, in `placement.origin`'s space.
/// - headerBottom: the lane header's bottom edge in that same space, or `nil` for a lane whose
/// header has not registered a frame yet — where the masonry answers alone.
/// - placement: the lane's resting grid geometry.
/// - heights: the lane's rendered cards' heights, in logical order.
/// - nominalHeight: the height an incoming, unmeasured card is assumed to have — the span the
/// create zone's cap is measured against, and the height each shadow draws at.
/// - current: the create slot currently proposed for this lane, or `nil`.
static func landing(
cursor: CGPoint,
headerBottom: CGFloat?,
placement: MasonryPlacement,
heights: [CGFloat],
nominalHeight: CGFloat,
current: Int?
) -> Landing {
if let headerBottom, cursor.y <= headerBottom { return .create(index: 0) }
let frames = placement.frames(heights: heights)
if let index = frames.firstIndex(where: { frame in
cursor.x >= frame.minX && cursor.x <= frame.maxX
&& cursor.y >= frame.minY && cursor.y <= frame.maxY
}) {
return .attach(index: index)
}
guard let slot = DropSlotMath.cardSlot(
cursor: cursor,
placement: placement,
heights: heights,
draggedHeight: nominalHeight,
current: current
) else { return .hold }
return .create(index: slot)
}
}
Kanban/UI/Board/LaneView.swift
+9
View File
@@ -132,6 +132,15 @@ struct LaneView: View {
)
}
.onDrag(startLaneDrag, preview: { dragReplica })
// **The header is the file drop's topmost position** (04-interactions.md ▸ Drag and drop,
// settled 2026-07-28: "a release on the lane header resolves to the topmost position —
// forgiving beats a dead stripe"). Its frame is registered rather than derived from the
// grid's because the grid is scroll-view *content*: scrolled down, its top edge climbs
// past the header and would stop being a boundary at all. The bar itself never moves.
.onGeometryChange(for: CGRect.self) { $0.frame(in: .global) } action: { frame in
drops.registry.update(header: frame, for: lane.id)
}
.onDisappear { drops.registry.removeHeader(lane.id) }
.overlay(alignment: .trailing) { newCardButton }
.contextMenu { laneMenu }
// The lane's half of the Style… popover. Anchored on the header because that is the