Windows: allow Discord to receive a shared push-to-talk shortcut #175

Bug report

Summary

On Windows, Hex appears to consume its configured push-to-talk key instead of passing it through. When I set Hex's dictation shortcut to F24 and configure Discord's Push to Mute binding to F24, Discord does not seem to receive the key, so Push to Mute does not activate while Hex is using the shortcut.

Steps to reproduce

1. On Windows, set Hex's dictation shortcut to F24.
2. In Discord, bind Push to Mute to F24.
3. Join a voice call and press/hold F24.

Expected behavior

Hex starts dictation and Discord also receives F24 so its Push to Mute binding can activate for the duration of the press. Releasing F24 should end both behaviors.

Actual behavior

Hex responds to the shortcut, but Discord does not appear to detect F24 and does not engage Push to Mute. The same Discord binding works when Hex is not running (please confirm this during triage if possible).

Environment

• Hex version: v2.3.0
• Operating system: Windows (version/build not yet provided)
• Dictation shortcut: F24
• Discord binding: Push to Mute on F24

Why this may happen

The Windows listener uses a WH_KEYBOARD_LL hook. In src/windows_input.rs, when the event matches the active dictation shortcut, the hook marks it as suppressed and returns 1 instead of calling CallNextHookEx. It does this for the matching key-down and key-up events. For a standalone F24 binding, those are the very events Discord needs to observe; suppressing them would prevent another application from acting on the same physical press. This is a source-based explanation of the likely mechanism, not a verified trace from the reporter's machine.

This may be intentional to keep the dictation shortcut from leaking into the foreground application. Could Hex provide an explicit pass-through/shared-shortcut option on Windows, or another supported way to let another app observe a shortcut while Hex also reacts to it? The behavior and tradeoffs should be clear, since forwarding a shortcut can also trigger the bound action in other applications.

Related report

Handy has a related Windows report about key bindings not passing through: cjpais/Handy#1314. Handy's closed #955 describes the opposite direction (a shortcut unintentionally reaching other apps) and was reported fixed in Handy 0.7.9, so it may not be the same bug or directly applicable fix.

Automatically submitted on behalf of the user by an AI agent.