Quick compare
For when the app is not open and the two things to compare are already in hand. A 420-pixel panel over whatever you were doing, which hands the pair to the main window rather than trying to show you a diff in it.
⌘⇧D (Ctrl+Shift+D elsewhere) opens a small panel in the top right of whichever display your cursor is on. Drop, paste or browse two things into it, press Compare, and the diff opens in the main window.
Both halves of this feature are off by default, and both are in Settings with what they do spelled out. A global shortcut takes its combination away from every other application on the machine, which is not a thing to switch on for somebody who has not asked.
It hands off, it does not compare#
The panel is 420×320. That is the wrong place to read a diff, and building a second copy of the workspace into it would be a second copy to keep in step with the first.
So the panel collects two inputs and passes them to the main window, which brings itself forward and runs the comparison. The panel hides first, so the handoff reads as one movement rather than two windows fighting over focus.
If there is no main window to hand to, it says so — "The main window is not open, so there is nowhere to hand this to." — instead of silently doing nothing.
It is always on top — including over full-screen apps on macOS — and it hides when it loses focus, which is what makes it feel like a panel rather than a window.
Filling it#
Three routes, all of them the ones the main window already uses:
| Drop | Drag a file onto the panel |
| Paste | Reads the clipboard — text, or an image, which is spilled to a temporary PNG so the image engine can open it |
| Browse… | The system file picker |
Whichever you use, the first fills Before and the second fills After. Each slot has a ✕ to clear it. Once both are filled, the detected engine appears as a chip — the same detection the Compare screen runs, so the panel cannot promise one engine and the window run another.
The clipboard watcher offers; it never fills#
Turn the watcher on and the panel notices when the clipboard changes while it is open, and shows a chip: Clipboard changed — 412 characters. Use it? Click it and the content is read. Ignore it and nothing happens.
That distinction is the whole design. Silently ingesting whatever somebody copies is not something a local-first tool should do, opt-in or not — the first thing you copy after opening the panel might be a password.
Why it polls a fingerprint instead of the clipboard#
Reading the clipboard properly is expensive and has side effects. For an image it decodes the bitmap and writes a temporary PNG to disk — because the image engine works from a path. Doing that on a timer, several times a second, for content nobody has offered, would be indefensible.
So the watcher polls a signature instead: a kind (text, image or empty), a
size, and a short hint — for text, the first and last two dozen characters; for an
image, its dimensions. That is enough to notice a change without the content
being ingested, and the actual read only happens after you click.
When the shortcut is already taken#
Registering a global shortcut can fail, and it fails for an entirely ordinary reason: another application already owns that combination. It is not an error condition, it is Tuesday.
TwinScope treats it as an answer rather than an exception. The registration result is recorded and reported as part of the panel's state, and the failure is logged — because a silent failure here is a feature that simply does not exist, with nothing to explain why. "I turned it on and nothing happens" has to have an answer.
The combination is fixed at ⌘⇧D rather than configurable: one binding, documented, and one thing that can conflict.
The same handoff powers deep links#
When you accept a twinscope:// link — from an exported
report's Open in TwinScope button, or from the VS Code extension — the two
files arrive in the main window through exactly this path, and the comparison runs.
One mechanism, so the two features cannot behave differently.