Handle mod key edge-cases in tiling WMs

This commit ignores keypresses when the mod key is held.

The reasoning is that an odd interaction happens between SDL applications and
tiling window managers. Tiling window managers like Xmonad and i3 usually use
the mod ("windows") key and a number to change workspaces. When changing
workspaces, however, the WMs still send the number key through instead of
"eating" it. It's not clear why, exactly, but it seems universal.

Mod+1 -> Goes to workspace #1
Mod+2 -> Goes to workspace #2
...
Mod+9 -> Goes to workspace #9

Most applications don't even see the number key being sent, so if you move to
workspace 1, Firefox won't type "1" into the browser bar, Vim won't type "1"
into your file, etc. But SDL applications, for whatever reason, DO see this
keydown. Of course, they'll handle it like a regular key press. So if you move
to workspace 1, which contains OpenRCT, it inadvertently toggles x-ray mode.

I first found this bug in another SDL game, The Powder Toy. After some
discussion with the devs, they fixed it like this, by ignoring keydown events
when the mod key is pressed, since the mod key is reserved for the window
manager anyway. It works well and should be in the next release.

c7619387ac...93b920a57f

I did the same thing here.
This commit is contained in:
Gaven Rendell 2021-04-02 13:40:01 -04:00 committed by Ted John
parent 6b965074ec
commit 7787bb46e0
2 changed files with 7 additions and 0 deletions

View File

@ -178,6 +178,7 @@ The following people are not part of the development team, but have been contrib
* (ocalhoun6)
* Sean Payne (seanmajorpayne)
* Soham Roy (sohamroy19)
* Gaven Rendell (Rendello)
## Toolchain
* (Balletie) - macOS

View File

@ -523,6 +523,12 @@ public:
#endif
case SDL_KEYDOWN:
{
// Ignore keydowns when mod is held. Handles edge cases
// where window managers don't eat the keypresses.
if (SDL_GetModState() & KMOD_GUI)
{
break;
}
_textComposition.HandleMessage(&e);
auto ie = GetInputEventFromSDLEvent(e);
ie.State = InputEventState::Down;