rzen
7eee0934ee
⌘X/⌘C/⌘V for cards and lanes per 04-interactions.md § Clipboard: - ClipboardStore stages full folder snapshots eagerly at the gesture into Application Support (at most the current copy; sweep at launch and on each copy purges what the pasteboard no longer references; a copy made before quitting pastes whole after restart) and writes the pasteboard a JSON manifest — every entry embedding its index.md, lane entries their cards' too — plus plain-text titles. - Cut is Finder-style deferred: items dim in place off pendingCut, void on pasteboard takeover (changeCount, no timers), source-board close, or per-item external tombstoning; the first armed paste moves the surviving originals whole (tombstoned interior cards land in the destination's trash), a second paste materializes copies from staging. - Paste anchors by the shared flatten-order rule (NewCardTarget's anchor, extracted); a tombstoned selection never anchors; lane paste reaches the right end and stays enabled on a zero-lane board; paste into the source board is the within-board lane duplicate; copies keep created, take fresh GUIDs, and strip tombstoned cards; trash-sourced copies strip deleted: at materialization; ⌘X is disabled on the trash side. - A degraded paste is loud, never silent: staging gone → the embedded index.md fallback lands content-intact, attachments absent, and a BannerCenter-phrased row names what was lost. - The standard Edit items validate through conditionally-attached onCommand handlers, so AppKit's enablement mirrors the availability predicates; text fields keep their own clipboard while focused. 879 unit tests (68 new). Claude-Session: https://claude.ai/code/session_01SR4XGjmBE16ZUYWpfFHXwY
77 lines
4.1 KiB
Swift
77 lines
4.1 KiB
Swift
/// Where ⌘V lands (04-interactions.md ▸ Clipboard), as pure functions of the selection, the
|
|
/// last-active lane, and the snapshot (`PasteTargetTests`).
|
|
///
|
|
/// The two rules verbatim, and each clause's branch below:
|
|
///
|
|
/// > Paste lands after the anchor card (or appends to a selected lane); a multi-selection anchors at
|
|
/// > its last member in flatten order — the ⌘N target rule's shared anchor. … **A tombstoned
|
|
/// > selection never anchors paste**: ⌘V stays enabled and behaves exactly as with nothing selected —
|
|
/// > a card payload appends to the last-active lane, a lane payload lands at the board's right end.
|
|
///
|
|
/// > **Lane paste** lands after the anchor lane — the selected lane, or the selected card's lane
|
|
/// > (several selected: the last, per the shared anchor rule); nothing selected = the board's right
|
|
/// > end.
|
|
///
|
|
/// Plus 04 ▸ The map's zero-lane clause: "New Card, Return-creation, and Paste with a *card* payload
|
|
/// disable via menu validation until a lane exists … Paste with a **lane** payload … stays enabled
|
|
/// and lands at the board's right end".
|
|
///
|
|
/// **Pure, for `NewCardTarget`'s reason** — the branches become lines of test rather than gestures to
|
|
/// drive, and the menu item's `disabled` reads the *same* answer as the paste's own target rather
|
|
/// than a second, hand-kept-in-sync condition.
|
|
///
|
|
/// ### What it deliberately reuses
|
|
///
|
|
/// The anchor is `NewCardTarget.flattenAnchor`, not a second walk: 04 says creation and paste share
|
|
/// one anchor ("the ⌘N target rule's shared anchor"), and two derivations of "the last member in
|
|
/// flatten order" would be two chances for them to disagree. The card branch goes further and reuses
|
|
/// `NewCardTarget.resolve` whole, because a card paste's *fallback* is the ⌘N rule's fallback too —
|
|
/// the last-active lane, then the first lane. Only the lane branch stops at the anchor, because its
|
|
/// fallback is the board's right end instead.
|
|
enum PasteTarget {
|
|
|
|
/// Where a card payload lands: which lane, and the position among that lane's rendered cards.
|
|
struct Cards: Equatable {
|
|
let laneID: ItemID
|
|
/// A position in the lane's logical card order, counted among what it renders *now* — the
|
|
/// convention every arrival path here takes (`BoardStore.receiveCards`).
|
|
let index: Int
|
|
}
|
|
|
|
/// The card payload's target, or `nil` on a **zero-lane board** — which is therefore the menu
|
|
/// item's `disabled` condition as well as the paste's refusal, so the two cannot disagree.
|
|
static func cards(
|
|
selection: ItemReferenceSet,
|
|
lastActiveLaneID: ItemID?,
|
|
snapshot: BoardModel
|
|
) -> Cards? {
|
|
guard let resolution = NewCardTarget.resolve(
|
|
selection: selection,
|
|
lastActiveLaneID: lastActiveLaneID,
|
|
snapshot: snapshot
|
|
),
|
|
let lane = snapshot.lanes.first(where: { $0.id == resolution.laneID && !$0.isDeleted })
|
|
else { return nil }
|
|
|
|
let rendered = lane.cards.filter { !$0.isDeleted }
|
|
// `insertionIndex` answers `nil` for "append", which is `rendered.count` — the same position
|
|
// said two ways, and the creation path's own degradation for an anchor that has since gone.
|
|
let index = BoardStore.insertionIndex(after: resolution.anchorCardID, among: rendered) ?? rendered.count
|
|
return Cards(laneID: lane.id, index: index)
|
|
}
|
|
|
|
/// The lane payload's slot among the board's live lanes — **always an answer**, zero-lane board
|
|
/// included, because lane paste "stays enabled and lands at the board's right end" whatever the
|
|
/// board holds. That is what makes it the other way out of a board with no lanes.
|
|
static func lanes(selection: ItemReferenceSet, snapshot: BoardModel) -> Int {
|
|
let lanes = snapshot.lanes.filter { !$0.isDeleted }
|
|
guard let anchor = NewCardTarget.flattenAnchor(selection: selection, snapshot: snapshot),
|
|
let position = lanes.firstIndex(where: { $0.id == anchor.laneID })
|
|
else {
|
|
// Nothing selected, a tombstoned selection, or a stale one: the right end.
|
|
return lanes.count
|
|
}
|
|
return position + 1
|
|
}
|
|
}
|