InputProcessor#keyTyped not fired for ESC, F1, F2, ... on Windows (not documented)

[soundasleep]

Issue details

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?

Reproduction steps/code

public class TextRenderTest extends ApplicationAdapter {
	
	@Override
	public void create() {	
		Gdx.input.setInputProcessor(new InputAdapter() {

			@Override
			public boolean keyUp(int keycode) {
				System.out.println("keyUp = " + keycode);
				return false;
			}

			@Override
			public boolean keyTyped(char character) {
				System.out.println("keyTyped = " + character + " (" + ((int) character) + ")");
				return false;
			}
			
		});
	}

	@Override
	public void render () {
		// etc
	}
}

Typing in h, <backspace>, <enter>, <escape>, <F1>:

[h]
keyTyped = h (104)
keyUp = 36
[<backspace>]
keyTyped = � (8)
keyUp = 67
[<enter>]
keyTyped = 
 (10)
keyUp = 66
[escape]
keyUp = 111
[F1]
keyUp = 131

Version of libGDX and/or relevant dependencies

• libgdx 1.12.0
• lwjgl 3.3.3
• Windows 10.0
• OpenJDK 64-Bit Server VM 16.0.2+7-67

Please select the affected platforms

• Android
• iOS
• HTML/GWT
• Windows
• Linux
• macOS

[tommyettinger]

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.