Detect macOS system-wide hotkey conflicts (Carbon `CopySymbolicHotKeys`)

[samkeen]

Optional, and only worth doing after #121 (customizable shortcuts) — until a user can pick their own chord, there's nothing to warn them about.

What's possible. CopySymbolicHotKeys() (HIToolbox) returns the system's symbolic-hotkey table: kHISymbolicHotKeyCode, kHISymbolicHotKeyModifiers, kHISymbolicHotKeyEnabled — Spotlight, Mission Control, screenshots, input-source switching and the rest. Public header, Carbon-era; verify the deprecation annotation against the current SDK before committing to it.

What it costs. An objc2/CoreFoundation dependency in b2-desktop, unsafe FFI (repo policy: a // SAFETY: per block stating the invariant that makes it sound — model.rs's weights mmap is the worked example), and virtual-keycode → character translation via UCKeyTranslate + TISCopyCurrentKeyboardLayoutInputSource, because the API speaks keycodes and the registry speaks characters. Non-trivial FFI for what is ultimately an advisory string.

The hacky alternative, explicitly rejected. Shelling out to defaults read com.apple.symbolichotkeys and parsing AppleSymbolicHotKeys — a dict keyed by undocumented magic integers whose meanings you'd hard-code. It works, plenty of apps do it, and it's exactly the kind of thing this repo would call a hack.

What is not possible in any supported way. Third-party global hotkeys — Raycast's ⌘Space, Alfred's ⌥Space, Rectangle's ⌃⌥arrows. Nothing enumerates another process's RegisterEventHotKey or CGEventTap claims. Any curated "commonly taken" list is a guess with a shelf life, and would go stale silently.

Why Low. The empirical probe in #121 already covers most of the practical value for free, and stays true across OS updates and third-party installs in a way a static table can't. This buys pre-emptive warnings (naming the conflict before the user presses it) for a meaningful chunk of unsafe FFI — a real gain, but a small one on top.

Left over from the keyboard-registry work in #118 — Layer 4 of the collision-detection plan, deferred there on this reasoning.

[samkeen]

Closing as not planned — the cost/benefit doesn't hold up.

The whole value of CopySymbolicHotKeys was pre-emptive warning: naming a conflict before the user presses the chord. But the recorder in #121 is a place the user goes deliberately to press a chord. If macOS has claimed it, the keydown never arrives, and they find out at exactly the moment it matters — while they're choosing, with the chord in front of them. The pre-emptive warning buys a few seconds of foresight on one screen.

Against that: an objc2/CoreFoundation dependency in b2-desktop, unsafe FFI blocks each owing a // SAFETY: invariant, and UCKeyTranslate + TISCopyCurrentKeyboardLayoutInputSource keycode→character translation because the API speaks keycodes and the registry speaks characters. That's a non-trivial, macOS-version-sensitive surface for an advisory string.

And it would still be the incomplete half. It can't see Raycast's ⌘Space or Rectangle's ⌃⌥arrows — nothing enumerates another process's RegisterEventHotKey claims. The probe covers those, stays true across OS updates and third-party installs, and needs no FFI at all. Adding the table would mean maintaining two mechanisms where the cheaper one has strictly better coverage.

Reopen if the probe turns out to under-report in practice badly enough that users can't tell "the OS took it" from "B2 is broken" — that's the failure mode that would change the math.

---

Generated by Claude Code