Closed hut closed 6 months ago
I'm pretty sure that the keys are synthetic: true
, which means that you don't have to handle them and they are reported as a part of the keys being latched/released during the focus change.
You don't have to start any action from them and given that input on X11 is global there's nothing wrong with that.
Great lead! Thank you. This might well be it. Bevy doesn't filter out synthetic keys.
I will close this issue for now and investigate.
Description
General issue
Pressing window manager keys (such as alt+tab) outside the winit window which change focus to the winit window will cause winit to erroneously reports the key as being pressed.
For example, on X11, winit version 0.30.0, in the example "control_flow", when I press "Alt+r" (my window manager key to switch workspaces) to enter the workspace where the winit window is focused, the "Request Redraw" action of the example (bound to the "r" key) is unintentionally triggered.
This is contrary to any UI application out there: No other application will have any action triggered through my workspace switching keys. The only exception I can think of is one Unity Engine game.
Why am I bothered by this exactly?
I'm writing an application with the "bevy" framework which uses winit for key handling. Whenever I use window manager key bindings to change focus, I unintentionally trigger actions in the application. Worse yet, those keys get stuck in a "permanently pressed" state, triggering the actions forever, until I press the respective key once again.
This is driving me crazy. Any pointers to a solution would be greatly appreciated. (I tried checking for whether the window is focused, this does not help.)
Thank you.
OS and window mananger
ArchLinux, i3 window manager on X11 alongside with KDE (no compositor).
Winit version
0.30.0