fix(shortcuts): scope OS-level key blocking to push-to-talk triggers#12
Merged
Conversation
Dev builds (productName ending in "Dev") now use the window title "Parler Dev" so they can't be confused with a production Parler window.
Parler used a single blocking handy-keys HotkeyManager and registered EVERY binding (transcribe, pause, cancel/escape, show_history, copy_latest_history, action digits, …) into it. handy-keys' blocking manager installs an active CGEventTap (Default mode, head-inserted at the Session level) and consumes any keystroke matching a registered combo — for ALL applications downstream. The result: a single misbehaving or overly-broad binding could swallow keys system-wide, which breaks keystroke monitoring for other apps (Klack stops detecting keys, the macOS shortcut recorder only sees modifier keys, etc.) — i.e. Parler appears to "hijack" the keyboard. Fix: run two managers in the manager thread. - A blocking manager that ONLY handles push-to-talk transcribe triggers (is_transcribe_binding), which genuinely need suppression so holding e.g. option+space doesn't type spaces. - A passive (non-blocking) manager for every other binding. It detects the shortcut but can never consume a keystroke. So at most the configured transcribe trigger combos are ever blocked; cancel/escape, pause/F6, history and action-digit keys are no longer swallowed globally. Also includes the in-progress recording-capture suppression safety net (is_capturing / MAX_RECORDING_DURATION) that auto-expires suppression if the frontend never calls stop_recording.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problème
Klack ne détecte plus les frappes et l'enregistreur de raccourcis macOS ne voit que les modificateurs (⌘/⌥/⌃) — symptôme classique d'une app qui hijacke le clavier.
Diagnostic (via
CGGetEventTapList) : Parler était le seul tap tiers actif (modeDefault, inséré en tête au niveau Session) captant les keyDown. La cratehandy-keysen mode bloquant consomme (retourneNULL) toute frappe matchant un raccourci enregistré — pour toutes les apps en aval. Or Parler enregistrait tous ses bindings (transcribe, pause, cancel/escape, show_history, copy_latest_history, action 1-9…) comme bloquants. Un binding trop large ou un tap dégradé sous charge avale alors des touches à l'échelle système.Fix
Deux managers dans le thread de gestion :
is_transcribe_binding) — ils doivent être supprimés (sinon mainteniroption+spacetaperait des espaces).Résultat : au pire seuls les combos transcribe configurés sont bloqués ; Escape, F6, history, et les touches chiffres d'action ne sont plus avalés globalement.
Inclut aussi le garde-fou de suppression pendant l'enregistrement (
is_capturing/MAX_RECORDING_DURATION).Test
cargo check✅Pour mettre à jour en local