rzen
797d020d01
Phase 3 finishes the pivot at the surface. One card face serves two containers: CardFaceView extracted with a role — board or trash — so stripe, tint, chip, selection stroke, cut dim, marquee registration, and drag are shared by construction, the trash side differing only in its absences: no Open, no rename, no Style, no file-hover highlight, and a Delete that goes through the confirmation host. The column rewrote around the lanes' own single-column masonry so drag reflow reads as positional slides; chrome stays the hatched header, symbol, and count — 11 gives Empty Trash to the File menu alone. Two real grammar bugs die here: plain Backspace on a trash selection purged without the confirmation the menu raises, and the context menu's Delete resolved against the standing selection, so right-clicking a trash card under a board selection silently did nothing — it now stages the clicked set explicitly. Open, Rename, Style, and Empty Trash validation became testable store seams; the column is one named accessibility container of ordinary card elements. The tombstone era is swept: deleteItem, restoreItem, stripTombstonedChildren — dead since lane copies stopped nesting trash — the restore verb, the unreachable put-back banner row, and every quasi-lane doc comment. Claude-Session: https://claude.ai/code/session_01SR4XGjmBE16ZUYWpfFHXwY
79 lines
4.2 KiB
Swift
79 lines
4.2 KiB
Swift
import AppKit
|
|
import SwiftUI
|
|
|
|
// MARK: - The Edit menu's clipboard row
|
|
|
|
/// Edit ▸ Cut / Copy / Paste (⌘X / ⌘C / ⌘V) on the board — 11-command-nexus.md's Edit row, whose
|
|
/// scope is "Board window: cards and lanes … in the trash, ⌘C copies out and ⌘X/⌘V is the keyboard
|
|
/// restore path … paste never targets the trash; text editors: standard text clipboard".
|
|
///
|
|
/// ### Why this is a responder answer and not three menu items
|
|
///
|
|
/// **Select All's precedent, exactly** (`BoardView`): the standard Edit menu already carries these
|
|
/// three, and AppKit dispatches `cut:`/`copy:`/`paste:` down the responder chain, so the board
|
|
/// answers them as a responder. Adding items of our own would put a second "Copy"-titled row in the
|
|
/// menus, which titles-are-API forbids outright (04-interactions.md ▸ Configurable bindings) — a
|
|
/// custom binding is stored against a title, and two rows sharing one would be ambiguous.
|
|
///
|
|
/// ### Availability is the handler's presence
|
|
///
|
|
/// `onCommand(_:perform:)` takes an **optional** action, and a `nil` action means the view does not
|
|
/// respond to that selector at all — which is precisely what AppKit's automatic menu validation
|
|
/// reads. So attaching the handler conditionally *is* the validation: there is one condition per
|
|
/// command, it decides both whether the item is enabled and whether the gesture does anything, and
|
|
/// the two can never disagree because they are the same expression.
|
|
///
|
|
/// The conditions themselves live on `ClipboardStore` (`canCopy`/`canCut`/`canPaste`), beside the
|
|
/// gestures they gate, for the reason every rule in this codebase that can be a named predicate is
|
|
/// one: an item that is going to no-op should not look available.
|
|
///
|
|
/// ### The focused-editor rule, twice over
|
|
///
|
|
/// A focused text field consumes these selectors natively, so ⌘X/⌘C/⌘V inside an inline title editor
|
|
/// stay text operations without anything here doing the arithmetic. The predicates still refuse while
|
|
/// an editor is open (04 ▸ Grammar: "board-scoped menu commands … disable via menu validation"),
|
|
/// which is belt over braces — but a board command that stayed armed under an editor is exactly the
|
|
/// fall-through 04's fixed grammar is careful to rule out.
|
|
extension View {
|
|
|
|
/// Attaches the board's clipboard responders, each only while its command applies.
|
|
func boardClipboardCommands(store: BoardStore, clipboard: ClipboardStore) -> some View {
|
|
self
|
|
.onCommand(#selector(NSText.cut(_:)), perform: clipboard.canCut(from: store) ? {
|
|
clipboard.cut(from: store)
|
|
} : nil)
|
|
.onCommand(#selector(NSText.copy(_:)), perform: clipboard.canCopy(from: store) ? {
|
|
clipboard.copy(from: store)
|
|
} : nil)
|
|
.onCommand(#selector(NSText.paste(_:)), perform: clipboard.canPaste(into: store) ? {
|
|
clipboard.paste(into: store)
|
|
} : nil)
|
|
}
|
|
}
|
|
|
|
// MARK: - The deferred cut's treatment
|
|
|
|
extension View {
|
|
|
|
/// **Cut items dim in place until paste moves them** (04-interactions.md ▸ Clipboard).
|
|
///
|
|
/// The same reduced opacity a trash card wears while it is being dragged out, and for the same reason:
|
|
/// the item is still there, still selectable, still the user's — it is simply spoken for. A cut
|
|
/// item is deliberately *not* lifted out of the layout the way a dragged one is; a Finder-style
|
|
/// deferred cut promises the board looks unchanged until the paste lands.
|
|
///
|
|
/// Membership is read straight off `TransientBoardState.pendingCut`, which is where the rules
|
|
/// already live: a reload ejects a member that crossed into the trash or vanished (so a deleted cut card undims by
|
|
/// itself), and `ClipboardStore` clears the set outright when the cut is consumed or voided.
|
|
func cutTreatment(of id: ItemID, in store: BoardStore) -> some View {
|
|
opacity(store.transient.pendingCut.ids.contains(id) ? ClipboardTreatment.dimmedOpacity : 1)
|
|
}
|
|
}
|
|
|
|
/// The one number the cut's treatment is (03-board-ui.md § Motion keeps every duration and curve in
|
|
/// `Motion`; this is neither, but it is the same "no literal at a call site" rule applied to the one
|
|
/// value three views share).
|
|
enum ClipboardTreatment {
|
|
static let dimmedOpacity: Double = 0.45
|
|
}
|