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 }