GreenLightning/Keyboard Input Handling.txt

## Keyboard Input Handling.txt
Keyboard Input Handling

Keyboards are used in two different ways: As a way to enter text or as an array of buttons each of which has a different function. An input API should therefore provide you two kinds of information: which text was entered and what buttons were pressed.

For text I would actually prefer a string, because the most common thing to do is to append it to some form of buffer. If the input API gave you an UTF-32 char, you would have to convert it into UTF-8 before appending it to the buffer.

For the other kind of information - what buttons are pressed - the API should give you a "key position id". Note that I am avoiding the words scan code or virtual key code. The "key position id" treats keys more like buttons and it totally ignores what label is on each key. One important difference between keyboards is that US keyboards have 104 keys, while European keyboards have 105 keys (I don't know about other parts of the world). This is a difference that would need to be encoded in the "key position id".

For anything that is not text input you would use the "key position id". There should also be a function which converts a "key position id" into a key description based on the current keyboard layout. For example, if you have a first person game and use the typical four keys for player movement, on a QWERTY layout the function should return WASD, but on a Dvorak layout it should return ,AOE for the same for "key position id"s and you can display that to your user if you want to tell them how to move.

The "key position id" should also be used for keyboard shortcuts. For example, I use a German keyboard which has the Z and Y keys swapped, but the undo shortcut in most applications is still CTRL+Z, which is harder to reach for me. Had the applications used the "key position id" system, the shortcut would have been CTRL+Y, but the Y key is right next to my X key and thus easier to reach for me.
	Keyboard Input Handling

	Keyboards are used in two different ways: As a way to enter text or as an array of buttons each of which has a different function. An input API should therefore provide you two kinds of information: which text was entered and what buttons were pressed.

	For text I would actually prefer a string, because the most common thing to do is to append it to some form of buffer. If the input API gave you an UTF-32 char, you would have to convert it into UTF-8 before appending it to the buffer.

	For the other kind of information - what buttons are pressed - the API should give you a "key position id". Note that I am avoiding the words scan code or virtual key code. The "key position id" treats keys more like buttons and it totally ignores what label is on each key. One important difference between keyboards is that US keyboards have 104 keys, while European keyboards have 105 keys (I don't know about other parts of the world). This is a difference that would need to be encoded in the "key position id".

	For anything that is not text input you would use the "key position id". There should also be a function which converts a "key position id" into a key description based on the current keyboard layout. For example, if you have a first person game and use the typical four keys for player movement, on a QWERTY layout the function should return WASD, but on a Dvorak layout it should return ,AOE for the same for "key position id"s and you can display that to your user if you want to tell them how to move.

	The "key position id" should also be used for keyboard shortcuts. For example, I use a German keyboard which has the Z and Y keys swapped, but the undo shortcut in most applications is still CTRL+Z, which is harder to reach for me. Had the applications used the "key position id" system, the shortcut would have been CTRL+Y, but the Y key is right next to my X key and thus easier to reach for me.