How does one listen for numeric input? I want to cover all following cases and similar:
- the number row on qwerty (without shift)
- the number row on azerty (with shift)
- the number row on a Thai keyboard layout
- any other keyboard layout that doesn’t use Arabic numbers
- the numpad keys
SDL_KeyCode does not work, as I need to check for shift manually depending on the the layout, which I don’t know. SDL_Scancode obviously has the same problem. SDL_TextInput seems also bugged as the input wouldn’t be reliable for countries/regions with non-Arabic number systems. Eg: you type the key on SDL_SCANCODE_5, but the resulting TextInput event might be some Thai character (meaning also 5, but not the ASCII “5”).
How would I go about covering actual numeric input, universally?
If I understood correctly, pressing the location where the KEY 5 is should trigger the SCANCODE is 5, no matter the keyboard configuration and layout (seems that is what you getting, and seems correct). What changes is the Keycode.
Since scancode is keybord independent and based on USB standard, in other hand keycode depends on input and layout.
https://wiki.libsdl.org/CategoryKeyboard
Yes, scancode 5 is indeed corresponds to the button of the 5-key. But when I’m on azerty, I should hold shift. So checking scancode itself is incorrect here, as that would trigger without a shift. On the other hand, on qwerty, you not need to press Shift. Yet, the scancodes AND keycodes for both layouts are the same. It indeed still is the keycode for the 5 key, as five is on the same key on that layout.
So my best bet so far is to use text-input events and check for the ascii string “5”, which would make things incompatible with non-arabic number input.
For reference; there are apparently quite some ways of writing down numbers: https://en.wikipedia.org/wiki/Numerical_digit#Numeral_notation_in_various_scripts
For text input you should always use text events.
Checking a Scancode or Keycode and the state of shift is completely useless, because even if the Keycode without shift corresponds to the buttons character (which usually is the case except for the number-keys on AZERTY), you have no way of knowing what the character you’d get with Shift is (because that’s layout dependent).
In addition to these problems, there’s also composed characters that you get from pressing more than one key, for example with “dead keys” where you first press ´ and then e and get é as a result (I think there exist a lot more input-schemes for non-western languages). So in those cases the keycode generally isn’t useful by itself to determine what character the user would get.
By the way, in recent versions of SDL2 (I forgot which version introduced this, but I’m sure it’s in the latest version at least), SDL_SCANCODE_0, …, SDL_SCANCODE_9 will always result in the corresponding keycodes, even on AZERTY where you normally have to press shift to get the numbers.
For key bindings in games (e.g. “press 1 to select first weapon, press 2 for second weapon, …”) this makes most sense.
I don’t really know how to solve your problem, but it seems like a really hard one - it’s not like you “only” have to check for the equivalents of 0,1,…,9 in whatever script and then otherwise treat it like an arabic number - it seems like some scripts have separate symbols for 10 or 100 or 1000 or whatever that you’d also have to handle, see https://en.wikipedia.org/wiki/Chinese_numerals
So it seems like keycodes or scancodes really won’t get you far for non-arabic numbers.
Maybe there’s libs that can parse numbers from any language from text input?
Does anyone know if people using Chinese or Thai or Vietnamese or … layouts expect to input numbers into computers in their native script (instead of as latin numbers)? Or do they maybe only use their native numbers in text and arabic for calculations (in computers, like in Excel or a calculator)?