Add key name lookup

[depp]

For the next version, add code to look up the human-readable "key name" for a key. This will be platform-specific, and it will also depend on the user's current key mapping. For example, KEY_A will have the name "A" on a computer with a US keyboard layout and it will have the name "Q" if the computer uses a French keyboard layout.

[techtonik]

How about standard for naming those keys? Right now everybody invents the names. Like LEFT in SDL, ArrowLeft in USB HID and LeftArrow somewhere else. I'd prefer CamelCase SDL convention.

[depp]

That's a very good point.

If anything, I would prefer something derived from the USB HID names since they're part of a standard, but not all USB HID names are valid identifiers (e.g. *) and the full HID names are a bit verbose ("Keyboard a and A"). Now that I'm looking, the library source uses one convention for the enum (KEY_$x and KP_$x) and a slightly different convention for the id strings ($x and KP$x), which is less than optimal.

On the other hand, short names are kind of nice.

[techtonik]

I guess USB HID didn't think about key names consistency even though they are most likely to be used in macros for different programs. So making some work beforehand and then submitting to USB HID may be a good option.

For example, Far Manager on Windows records keypresses as Keys("AltE R E A D M E F4 PgDn PgDn Enter"), which what I would type to search for README file, open it in editor and insert newline after two pages. I would stick to this convention as it is already there. Actually, it looks like Far Manager records characters in specific layout and maintains a mapping of layout characters to keys to know that recorded Keys("Alt F9 щ у") in Russian layout is the same as Keys("Alt F9 o e") if the character is being used to navigate menus etc. But that's a tricky use case, although a practical one to draft specification from.

So, in the story above canonical key names match for keys that are not letters/digits. For letters/digits I'd like to see separation between KeyA and typed A character, which can be also a or Ф or ф depending on layout and Shift state. Maybe introducing a registry of "reverse layout mapping" could be an additional feature, to make sure that you can find KeyA even if user hits a key labelled Ф on his layout while trying to record such shortcut in settings.

[depp]

To clarify, there would be two types of names for keys, but they're separate (so you can use the same name in both for different keys).

• The Key ID identifies the location of the key, independent of keyboard layout. This should be taken from the USB HID tables exclusively. This is never localized. This should be stored internally for key bindings, e.g., in configuration files.

• The Key Label is specific to the keyboard layout, and is localized. This should be displayed to the user.

For example, let's say the leftmost key on the home row is bound to "move left" and the user has a French keyboard layout. The config file would have a line like A: MoveLeft, and the game would print a message to the screen like "Press Q to move left". This information has to be gleaned at runtime from the appropriate APIs, some of which are fairly messy, and all of which are completely incompatible with each other.