-
Notifications
You must be signed in to change notification settings - Fork 0
Hotkeys and Platform Notes
Implementation: Win32 RegisterHotKey / UnregisterHotKey (user32.dll), dispatched through WM_HOTKEY in the WndProc.
How it works:
- Hotkeys are registered system-globally: they fire even when the app is minimized to the tray or another window has focus.
- Start hotkey default: none (configure manually).
- Stop hotkey default:
F10. - Setting both hotkeys to the same combination is blocked with an inline error.
- Hotkey bindings persist in
%APPDATA%\QuadClicker\settings.json.
Supported keys: single keys and modifier combinations (Ctrl, Alt, Shift, Win). Use the capture field in the GUI — click it and press the combination you want.
No special permissions required on Windows.
Implementation: NSEvent.addGlobalMonitorForEvents(matching: .keyDown) — monitors key-down events globally.
Accessibility permission required. macOS requires you to grant the app Accessibility access before global hotkeys work:
- Open System Settings → Privacy & Security → Accessibility
- Click the lock and authenticate
- Add QuadClicker or toggle it on if already listed
The app calls AXIsProcessTrusted() before attempting to install monitors. If permission is not granted, the monitor is not registered and hotkeys are silently inactive.
Note: macOS status is unverified — the app has never been compiled or run. These details are sourced directly from the Swift implementation (Core/HotkeyManager.swift).
Implementation: XGrabKey on the root window, polled from a dedicated background thread. Lock-mask permutations (CapsLock, NumLock) are handled by grabbing all four combinations.
Works on: any X11 session (GNOME on X11, KDE on X11, etc.).
No special permissions are needed beyond having an active X display connection.
Global hotkeys are not supported under Wayland.
The HotkeyManager detects the Wayland platform at startup using QGuiApplication::platformName() == "wayland" and immediately sets itself to unsupported (m_supported = false). No hotkey registration is attempted. The GUI displays a note to that effect.
There is no KDE D-Bus fallback implemented. Documentation that suggests otherwise is incorrect — the source contains only the X11 path.
Workaround: use the Start/Stop button in the GUI or the system tray context menu. If you need hotkeys on Wayland, run under XWayland (set DISPLAY and ensure an X compatibility layer is active) — under XWayland the X11 hotkey path works.
Future milestone: implementing org.kde.kglobalaccel (KDE) or org.freedesktop.portal.GlobalShortcuts (xdg-desktop-portal) D-Bus shortcuts is tracked but not implemented.
The Qt app builds and runs under WSL2 with WSLg (XWayland-backed display). The XWayland compositor provides an X11 environment, so XGrabKey works and hotkeys function normally in that context. However, XTEST input events injected by the click engine are not visible to other XInput observers under XWayland — click delivery on a real Linux desktop is unaffected.
uinput (Wayland input injection path) is unavailable in WSL; it requires a real Linux session with /dev/uinput access.