Utilize SDL2's keyboard capture logic to inhibit window manager shortcuts #5934
Conversation
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
Use `SDL_SetWindowKeyboardGrab' to inhibit keyboard shortcuts.
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Attempts to inhibit window manager shortcuts by using
SDL_SetWindowKeyboardGrab(SDL_Window*, SDL_bool)introduced in SDL 2.0.16 to capture the keyboard. There are a bunch of caveats -- like if another application attempts to grab the keyboard after us, they win and we lose our grab, or that not all shortcuts can be inhibited on all platforms (Windows always capturesCtrl+Alt+Delfor example, irrespective of our application) -- but it works for the majority of cases.Adds a simple keyboard mapping just like for other properties like mouse capture (defaults to
Ctrl+F11, similar to mouse capture'sCtrl+F10), editable in the mapper tool just the same. Property is available in the config file as well, and restored on startup, with a big block of help text to make sure people are aware of the warnings and caveats associated with no-longer being able to use your WM to kill DOSBox-X if it gets stuck.Also hints to SDL/WM to inhibit
Alt+Tabtoo when fullscreen. As we have a dedicated fullscreen toggle to break out, and as applications inside DOSBox-X might utilizeAlt+Tabfor things like Windows' application switcher, it makes sense to capture this too. It's only set withSDL_SetHint(char*, char*), so it's overridable via environment variable if the user doesn't like it.As a sidenote, I believe I've added English and French translations to the menu entry correctly, but I'm not so hot with the rest of the languages for which there are translations files. They seem to include the English where yet untranslated so I've just copied that across verbatim to the rest of them.
This was all written and tested on Fedora Linux 43 x86_64, under both MATE X11 and FVWM X11 individually. It's largely based on existing work done in dosbox-staging/dosbox-staging#4338 for DOSBox Staging's similar issue (dosbox-staging/dosbox-staging#4306). Overall code layout attempts to mimic what's already in the DOSBox-X codebase and the files touched.
What issue(s) does this PR address?
Closes #4911
Does this PR introduce any breaking change(s)?
No, shouldn't do.
Additional information