You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure if this is intended behaviour, but at the very least it should be documented: keyUp and keyDown are fired for special keys (escape, F1, ...etc) on my Windows machine, but not keyTyped.
How do we know which keys will come in with keyTyped and not keyUp?
So, keyTyped() works with a char. There is no char in all of Unicode assigned to the Esc, F1, F2, F3... etc. keys, though there are at least two that are associated with Enter, and I believe there is a control character for Backspace and maybe also Delete. What would you want keyTyped() to use for its char key if there is no valid 16-bit char for a key (or key combination, such as Shift-F1)? This sounds like something to take up with the Unicode Consortium rather than libGDX, and because there is no technical limit to how many function keys (F1, F2, F3...) can exist, this is probably impossible in the general case. Phones also typically have buttons that PCs don't, such as volume rockers, and new hardware "keys" can be defined ad-hoc by new types of hardware. For the limited case, I made a dumb attempt to have a visible representation of keys for the purposes of keybinding (see here). It doesn't cover everything how I'd like it -- Escape is mapped to '☠', which can't easily be pasted without it turning into an emoji, but there is a non-emoji version in Unicode. That said, you wouldn't want keyTyped() to cause visible chars to show up in a TextField...
This could probably be documented better, sure. A lot of things could. The main way you can tell if keyTyped will receive a char in its event handling is if that key would affect a TextField in some unambiguous way. That means A and a will come through, but Esc and F1 will not. Things get significantly more complex when non-US keyboard layouts are involved, which is an ongoing thing with either LWJGL3 or GLFW (which LWJGL3 depends on). Things get even more complex with Android and iOS text entry, which can enter whole words at a time,, or emoji (which aren't really supported by BitmapFont), and can autocorrect text that was already partially typed.
So yeah. It's a can of worms, and it's not just our can.
Issue details
I'm not sure if this is intended behaviour, but at the very least it should be documented:
keyUp
andkeyDown
are fired for special keys (escape, F1, ...etc) on my Windows machine, but notkeyTyped
.How do we know which keys will come in with keyTyped and not keyUp?
Reproduction steps/code
Typing in
h
,<backspace>
,<enter
>,<escape>
,<F1>
:Version of libGDX and/or relevant dependencies
Please select the affected platforms
The text was updated successfully, but these errors were encountered: