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

The card window's ⌘V drops its picture branch — the attachments header now offers one instead

Browse Source 
Raw image data on a card window's ⌘V was a keyboard shortcut with no visible
trigger; the sidebar's Attachments header now grows a quiet control — beside
the existing add affordance, present only while the pasteboard holds a
picture this card could take — that pastes it through the exact seam the
retired branch used (ClipboardStore.pasteImage(intoCard:in:), the board's
"Paste Image into Card" row's own call). The file-URL branch stays on ⌘V; a
Finder copy is still unambiguous. CardBodyTextView's paste-yield mechanism
needed no change at all — it forwards by capability, not by picture-specific
logic, so a screenshot ⌘V with the body editor focused is now a genuine
no-op there, served by the new control instead.

The pasteboard's re-read gains a fourth checkpoint — a window becoming key —
alongside menu-tracking, ⌘-down and app activation: a persistent visible
control has to read true continuously while its window is frontmost, not
only at the instant a menu or chord probes it.

Claude-Session: https://claude.ai/code/session_014PtZdPwqZuqEDLc6wZMtEy
This commit is contained in:
rzen
2026-08-09 10:37:55 -04:00
parent 546fd2840f
commit 200fbce276
8 changed files with 343 additions and 49 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Kanban/App/CardWindowHost.swift
+38 -16
View File
@@ -495,11 +495,12 @@ struct CardWindowHost: View {
.onChange(of: placement.card.hero.value, initial: true) { _, hero in
attachments.hero = hero
}
// **⌘V in this window pastes onto this card** (04-interactions.md ▸ Clipboard's
// image-data and file-URL branches). Here rather than inside `CardWindowView` because the
// availability is the clipboard's observable reading and this is where a store, a card id
// and the app-wide clipboard are all in scope at once — the same join `configureAttachments`
// makes for the other two writes.
// **⌘V in this window pastes a Finder-copied file onto this card** (04-interactions.md ▸
// Clipboard's file-URL branch; the image-data branch retired 2026-08-09 for the
// attachments header's paste-image affordance, wired below through `configureAttachments`).
// Here rather than inside `CardWindowView` because the availability is the clipboard's
// observable reading and this is where a store, a card id and the app-wide clipboard are
// all in scope at once — the same join `configureAttachments` makes for the other writes.
.cardWindowPaste(
store: store,
cardID: placement.card.id,
@@ -724,7 +725,9 @@ struct CardWindowHost: View {
session.rawSourceIsActive = { [rawSource] in rawSource.isActive }
session.rawSourceApply = { [rawSource] in rawSource.applyAndLeave() }
session.rawSourceCancel = { [rawSource] in rawSource.cancel() }
Self.configureAttachments(attachments, store: store, cardID: cardID, undo: session.undo)
Self.configureAttachments(
attachments, store: store, cardID: cardID, undo: session.undo, clipboard: appModel.clipboard
)
Self.configureComments(session.comments, store: store, cardID: cardID, on: session.undo)
}
@@ -827,17 +830,23 @@ struct CardWindowHost: View {
}
}
/// Points the attachments section at its card — **the one place Add Attachment… and Remove
/// learn which card they act on** (05-card-window.md ▸ Attachments).
/// Points the attachments section at its card — **the one place Add Attachment…, Remove and the
/// paste-image affordance learn which card they act on** (05-card-window.md ▸ Attachments).
///
/// Both seams are the store's own bracketed methods, unchanged: `importAttachments(_:toCard:)`
/// is the *same* call the board window's Finder drop makes, so a file added through ⇧⌘A, through
/// the header's plus, through a drop anywhere in this window, and through a drop on the card's
/// face on the board all take one path — one collision rename, one set of banners, one commit
/// shape. There is deliberately no card-window import of its own to keep in step with it.
/// Every seam is the store's or the clipboard's own bracketed method, unchanged:
/// `importAttachments(_:toCard:)` is the *same* call the board window's Finder drop makes, so a
/// file added through ⇧⌘A, through the header's plus, through a drop anywhere in this window, and
/// through a drop on the card's face on the board all take one path — one collision rename, one
/// set of banners, one commit shape. `pasteImage`/`canPasteImage` are `ClipboardStore
/// .pasteImage(intoCard:in:)`/`.canPasteImage(intoCard:in:)` the same way — the exact seam the
/// retired ⌘V image branch used, and the board's "Paste Image into Card" context-menu row still
/// uses (`CardFaceView`). There is deliberately no card-window import or paste of its own to keep
/// in step with either.
///
/// The store is captured **weakly**, `configureSession`'s rule: a panel still running after the
/// board window has gone should write nothing rather than resurrect a released store.
/// The store and the clipboard are captured **weakly**, `configureSession`'s rule: a panel or a
/// paste still running after the board window has gone should write nothing rather than
/// resurrect a released store — and the clipboard is app-wide and always outlives any one window
/// in practice, but the same discipline costs nothing to apply uniformly.
///
/// `static`, and taking every collaborator as a parameter, for `configureRawSource`'s reason:
/// the target resolution is invisible in a running window until it is wrong, and this shape is
@@ -846,7 +855,8 @@ struct CardWindowHost: View {
_ attachments: CardAttachments,
store: BoardStore,
cardID: ItemID,
undo: CardWindowUndo
undo: CardWindowUndo,
clipboard: ClipboardStore
) {
attachments.importFiles = { [weak store] urls in
store?.importAttachments(urls, toCard: cardID)
@@ -860,6 +870,18 @@ struct CardWindowHost: View {
attachments.setHeroFile = { [weak store] name in
store?.setHero(name, onCard: cardID, on: undo)
}
// **The retired ⌘V image branch's seam, now the header's control's** (04-interactions.md ▸
// Clipboard, re-ruled 2026-08-09). No undo step here either, `setHeroFile`'s neighbor and an
// import's own reason: an attachment arrival is not on the stack (13-native-undo.md ▸ Out of
// scope).
attachments.pasteImage = { [weak store, weak clipboard] in
guard let store, let clipboard else { return }
clipboard.pasteImage(intoCard: cardID, in: store)
}
attachments.canPasteImage = { [weak store, weak clipboard] in
guard let store, let clipboard else { return false }
return CardPasteImageAffordance.isVisible(clipboard: clipboard, cardID: cardID, in: store)
}
}
/// Points the raw-source outlet at its card — the outlet's three seams (05-card-window.md ▸ Raw
Kanban/App/ClipboardStore.swift
+28 -3
View File
@@ -48,9 +48,9 @@ import os
///
/// `NSPasteboard.changeCount` is a machine-wide counter, so a value that moved without this store
/// moving it means another app owns the pasteboard now. It is checked exactly where 04 says — menu
/// validation, app activation, and before every paste — and nowhere else. `payload` is observable
/// state rather than a computed pasteboard read precisely so the menu items' enablement re-evaluates
/// when it changes rather than whenever SwiftUI happens to rebuild them.
/// validation, app activation, before every paste, and a window becoming key — and nowhere else.
/// `payload` is observable state rather than a computed pasteboard read precisely so the menu items'
/// enablement re-evaluates when it changes rather than whenever SwiftUI happens to rebuild them.
///
/// **"Menu validation" is two checkpoints here, not a hook**: the commands validate by conditional
/// responder attachment (`ClipboardCommands` — availability *is* the handler's presence), which
@@ -62,6 +62,15 @@ import os
/// screenshot hotkey, ⌃⇧⌘4 — would leave ⌘V dead until the next app switch, which is the image
/// branch's headline gesture failing in the exact case it was built for. Both checkpoints are one
/// `changeCount` read in the common case, which is why they can afford to fire on every ⌘-chord.
///
/// **A window becoming key is the fourth checkpoint** (widened 2026-08-09 for the card window's
/// paste-image affordance, `CardPasteImageAffordance`): a visible control, unlike a menu item, has to
/// read true continuously while its window is frontmost rather than only at the instant something
/// probes it. Switching between two already-open windows of this app — no menu opened, no ⌘ pressed
/// — crosses neither of the first two checkpoints and stays inside one app activation, so the third
/// checkpoint misses it too; `NSWindow.didBecomeKeyNotification` is the moment that is left. Fired
/// for every window rather than filtered to card windows, for the same cost reason: one more
/// `changeCount` read on an already-cheap path.
@MainActor
@Observable
public final class ClipboardStore {
@@ -196,6 +205,22 @@ public final class ClipboardStore {
) { [weak self] _ in
MainActor.assumeIsolated { self?.refresh() }
})
// **The fourth checkpoint** (type comment ▸ takeover, widened 2026-08-09 for the card
// window's paste-image affordance): any window becoming key. The first three checkpoints
// exist for *menu* validation, which only ever runs when something is about to fire — but a
// visible control has to read true continuously while its window is frontmost, not only at
// the moment a chord or a menu happens to probe it. Switching between two already-open
// windows of this app crosses neither of those moments and stays inside one activation, so it
// needed a trigger of its own. Every window, not just card windows: cheap (one `changeCount`
// read in the common case, `refresh()`'s own guarantee) and simpler than teaching this store
// which window kind is asking.
stalenessObservers.append(NotificationCenter.default.addObserver(
forName: NSWindow.didBecomeKeyNotification,
object: nil,
queue: .main
) { [weak self] _ in
MainActor.assumeIsolated { self?.refresh() }
})
commandKeyToken = NSEvent.addLocalMonitorForEvents(matching: .flagsChanged) { [weak self] event in
// Local monitors run on the main thread, before the event reaches its window
// (`LocalModifierFlipWatch`'s note) — and the event is returned unchanged, always, for