Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Holding down keyboard keys on MacOS brings up special character menu #9268

Closed
increpare opened this issue Mar 14, 2024 · 2 comments
Closed
Milestone

Comments

@increpare
Copy link

increpare commented Mar 14, 2024

  • SDL version: 2-2.30.1
  • MacOS version: 14.0 (23A344) (Apple M1 Max)

Possibly relevant system setting:
I have the "ABC - Extended" keyboard layout selected.


Code snippet reproducing the issue:

The lazyfoo tutorial project here https://lazyfoo.net/tutorials/SDL/01_hello_SDL/mac/index.php - just with an empty window I get the behaviour. (This bug has already percolated through HaxeFlixel and OpenFL )


Observed behavior:

If I hold down certain keys on the keyboard that have variants/accents (like the A key, for instance), then a menu will appear to the top-left of the window (if in windowed mode):

Bildschirmfoto 2024-03-14 um 10 34 40

If I change the window instantiation to use SDL_WINDOW_FULLSCREEN_DESKTOP, then I get the menu appearing in the top-left of the screen:

Bildschirmfoto 2024-03-14 um 10 52 34

If I use SDL_WINDOW_FULLSCREEN then I do not get this behaviour (I haven't checked if the input isn't maybe otherwise affected though).

Expected behavior:

Unless I'm specifically inputting into a text field, I would not want this menu to appear. And in those cases, were it to appear, I would want it to appear in the correct location. Asking for perfect behaviour might be too much, but I would much prefer the menu never appear, rather than its current behaviour.


This is present in Haxe games like Dead Cells, so there must be some similarities in window instantiation/app settings.
Bildschirmfoto 2024-03-13 um 20 00 27

Screenshot of the behaviour occuring in HaxeFlixel 5.6.2:
Bildschirmfoto 2024-03-13 um 19 34 02

Screenshot of the behaviour in Lime 8.2.0-Dev:

Bildschirmfoto 2024-03-14 um 10 21 57

Looking for games/apps that don't exhibit this behaviour, in case it might be helpful - VVVVVV seems to use SDL2 (it contains libSDL2-2.0.0.dylib), but doesn't exhibit the behaviour.

Possible links to people possibly struggling with the same problem that I stumbled across while I was trying to solve it myself (sometimes it manifests as people reporting that key-repeats aren't getting sent):

https://apple.stackexchange.com/questions/332769/macos-disable-popup-showing-accented-characters-when-holding-down-a-key
https://www.reddit.com/r/runescape/comments/atudk0/macbook_whenever_i_press_and_hold_a_key_an_accent/
bus-stop/Termination#9
https://fsunuc.physics.fsu.edu/git/gwm17/glfw/commit/17a15a20f28ed95e0e69d403687416c023c77e7e
https://stackoverflow.com/questions/76546729/why-are-certain-repeated-keys-ignored-by-interpretkeyevents-in-nsresponder
https://fsunuc.physics.fsu.edu/git/gwm17/glfw/commit/17a15a20f28ed95e0e69d403687416c023c77e7e
smolck/uivonim#106 (comment)

@increpare increpare changed the title Holding down keyboard keys on MacOS brings up special character menu #2697 Holding down keyboard keys on MacOS brings up special character menu Mar 14, 2024
@slouken slouken added this to the 2.32.0 milestone Mar 14, 2024
@cgutman
Copy link
Collaborator

cgutman commented Mar 17, 2024

This popup is from the IME to allow you type accented letters that don't exist on the keyboard. It appears because SDL enables text input events by default. If you don't need the full IME capabilities (such as for typing a player name), calling SDL_StopTextInput() disables this behavior.

@increpare
Copy link
Author

Amazing, thanks. Okay, so this is the desired SDL default behaviour I guess, and better to be worked around in the individual engines that use it? Feel free to close if so. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants