[skyhilam]

What does this change?

On macOS, a keyboard shortcut can convert what's on the clipboard and put the result back on it, ready to paste. Main use: a screenshot taken with Ctrl held (Ctrl+Shift+⌘+4) is too large to paste into a chat. Press your shortcut, pick JPG/WebP or compress, then ⌘V the smaller picture.

• Order: files copied in Finder (file URLs, then NSFilenamesPboardType), else a picture (PNG, JPEG, HEIC, WebP, GIF, TIFF). With neither on the clipboard the shortcut does nothing — it never falls back to the file manager selection. Copied files that no longer exist give nothing (not Finder's icon).
• A clipboard picture becomes a one-item WebDrop with SaveOnlyConverted: it is saved where files from a browser go (Downloads by default), and only the result is kept.
• When the job finishes, ConversionService writes its outputs back to the clipboard: a file URL per result, and a single picture also as its own image data, so it pastes into Finder, chats and documents. A cancelled job leaves the clipboard alone. A partly failed job still copies its outputs, and the log carries the failed count next to the copied count.
• TriggerGesture.Clipboard works on any keyboard shortcut. The Shortcuts page shows a switch where the platform supports it (macOS only for now: IPlatformServices.SupportsClipboard). New strings are in every language.
• Off by default: no default gesture and no settings migration turns it on (settings schema stays 54). Whoever wants it adds a shortcut with keys of their own choosing and turns the switch on in Settings → Shortcuts — the global hook can't swallow keys, so a preset combination (Shift+⌘+V is Paste and Match Style in most text fields) would also reach the app in front.

Type of change

• Bug fix
• New feature or improvement
• New format or engine
• Translation
• Documentation
• Build, CI or dependencies

How was it tested?

• dotnet test: ClipboardShortcutTests in Core (3) and App (6, incl. the screenshots below), PasteboardPathsTests, LocalizationTests and the trigger/shortcuts-page tests pass. Full Filee.Core.Tests (722): only the 12 WebDownloaderTests fail on this machine (the sandbox denies binding a local socket; unrelated to this change).
• Tried it in the app (macOS 27, Apple Silicon, ad-hoc signed Filee.app): a screenshot copied with Ctrl+Shift+⌘+4, then the clipboard shortcut and a smaller format, pastes the converted picture. Files copied in Finder convert and paste as the new files, and a clipboard holding only text opens nothing.

Screenshots (UI changes)

Settings → Shortcuts: the clipboard switch off on the default Ctrl+⌥+Space and on for a user-added Ctrl+⌥+V (rendered by The_shortcuts_page_shows_the_clipboard_switch in Filee.App.Tests).

Checklist

• New UI strings are in all src/Filee.App/Assets/i18n/*.json files
• New third-party code or binaries are listed in THIRD-PARTY-NOTICES.md (none added)
• The PR does one thing (unrelated changes go in a separate PR)

🤖 Generated with Claude Code

[KnifeLemon]

Thanks, @skyhilam! Converting a screenshot on the clipboard and pasting the smaller result is a nice idea, and the clipboard handling (file URLs first, then picture data, a cancelled job leaves the clipboard alone) is careful. Two things need to change before it can go in:

1. Not on by default. Shift+⌘+V is Paste and Match Style in Pages, Mail, Notes, Slack, Google Docs and most text fields, and the hook can't hold the keys back. With this on for everyone (new installs and the schema 55 step), every Paste and Match Style with a picture or files on the clipboard would also open the donut over the app the user is typing in. Please drop the default and the migration: the clipboard switch is there in Settings → Shortcuts for anyone who adds a shortcut and turns it on, with the keys they choose. That also frees schema 55, which another PR needs.
2. No fallback to the Finder selection. When the clipboard holds neither files nor a picture, a clipboard shortcut should do nothing. Falling back to the file manager's selection means a shortcut with Active in: Everywhere converts whatever happens to be selected in a Finder window in the background, from any app, which isn't what someone pressing a "clipboard" shortcut expects. A short notice ("Nothing to convert on the clipboard") would be fine, or nothing at all.

Smaller points:

• In CopyResults, a job that partly failed still puts its outputs on the clipboard. That's fine, but please log the failed count too, so a support log shows why fewer files were pasted than copied.
• Please add a screenshot of the Shortcuts page with the new switch (light and dark), as the template asks.

New features usually start with an issue and an agreed plan here, so for the next one please open an issue first. For this one, the two points above are what's needed.

[skyhilam]

Thanks for the review — pushed b35d1ca addressing both points:

• Not on by default: the Shift+Cmd+V default gesture and the schema 55 migration are gone (CurrentSchemaVersion is back to 54, so 55 is free). The switch in Settings → Shortcuts is the only way in: add a shortcut with keys you choose and turn it on. TriggerGesture.ClipboardShortcut() is removed entirely.
• No Finder-selection fallback: a clipboard shortcut is now a terminal branch in the SelectionGesture handler. With neither files nor a picture on the clipboard it does nothing (a clipboard gesture on a platform without clipboard support also returns early). The empty case logs Nothing to convert on the clipboard, throttled like the empty-selection log.
• Failed count in CopyResults: the log now reads Put {Count} converted file(s) on the clipboard; {Failed} file(s) failed (same for the could-not-put warning, and a job that made nothing logs its failed count too). Covered by a new test with a partly failed job.
• Screenshots: light and dark are in the PR description now, rendered by the new The_shortcuts_page_shows_the_clipboard_switch test in Filee.App.Tests (the images are hosted on a side branch of my fork, pr-705-screenshots, since I'm pushing from the CLI — I'll delete that branch once this lands). The screenshots also show the updated note: "With neither, nothing happens." (updated in every language), and the ARCHITECTURE.md paragraph says the same.

Tests: ClipboardShortcutTests (Core 3, App 6), LocalizationTests, and the trigger/shortcuts-page tests pass. In the full Filee.Core.Tests run (722) only the 12 WebDownloaderTests fail on this machine because the sandbox denies binding a local socket — unrelated to this change. One thing I could not run locally is dotnet format --verify-no-changes (its build host needs a named pipe the sandbox denies); the builds of the touched projects are warning-clean, and CI will have the final say there.

And noted — next feature starts with an issue.

[KnifeLemon]

Thanks, @skyhilam! Both points are done:

• Not on by default: there's no default gesture and no migration. A clipboard shortcut exists only when someone adds one, with keys they choose.
• No fallback: with nothing convertible on the clipboard, the shortcut does nothing (a throttled log line).

The failed count is logged too, and the screenshots are in the description.

I pushed three small commits to bring the branch up to date with main:

• Italian and Indonesian: both languages reached main after this branch started, so I added the two strings in each.
• Korean: the note now uses the polite 해요 style of the rest of ko.json.
• Format check: the clipboard tests' object initializers now have one member per line.

CI is green on all platforms. Thanks for the careful clipboard handling!