# They key you selected in frontend is the key that you actually need to push (so if it says “Z”, you must press the “Z” key in game; it must respect keyboard layout). This is the bug that was reported

 # The key that is displayed in frontend must match the key that is saved in config file

 # (optional) Engine is able to convert the code to human-readable text. It's not a bug if it's not possible, however

 # Default key config works with MOST normal keyboards (100% perfect coverage not required as its unrealistic; owners of exotic keyboards are expected to reconfig)

=== A) Use keycode in frontend and config file, use scancode in engine (current broken approach) ===

Criteria:

 # No.

 # Yes.

 # No.

 # Yes.

Summary: The problem with our current approach is point 1. The frontend displays the wrong key. The fact that the game inconsistently uses keycodes AND scancodes is also a little insane. Any solution definitely must fix point 1, otherwise it gains us nothing

=== B) Use scancodes in frontend, engine und config. Crate a small helper program that queries scancode in frontend to replace the drop-down menu ===

 # Yes.

 # No obvious solution in sight. Maybe there is one?

   * Possible, hacky solution: Convert scancode to keycode using a hardcoded lookup table or something like that

   * https://github.com/hluk/qxtglobalshortcut/blob/16446200b699e0610b8a5fb20b74938225d81d87/src/xcbkeyboard.h#L249

 # Yes. Convert scancode to keycode with SDL_GetKeyFromScancode

 # No idea.

 * Note: Adding a new program only to grab the key seems a little insane, but it seems to work

 * Note: We have a mock-up of the keygrab program, but no code for the rest exists yet

Summary: This solution depends on whether 2) is solvable. We need to be able to render the correct key name in frontend, otherwise, this solution would be a regression. Another open question is how to store the keys in the config. Just the raw scancodes? Anyway, if we can figure all that out, then this approach is a valid solution.

=== C) Use keycodes in frontend, config und engine ===

Criteria:

 # Yes.

 # Yes.

 # Yes.

 # Meh. What will semi-break is the default config for e.g. French keyboards because of the number keys (for timer) which are secondary inputs, so owners of French keyboards need to reconfig.

Possible solutions for 4)

 * Allow numpad numbers as alternative input for timer keys

 * Implement user-selectable alternative keys for everything and add numpad keys as alternative input for timer by default

 * When detecting French keyboard on first launch, use different default keys (does not sound very stable ... Also, how to detect keyboard layout in Qt?)

 * Non-solution: Ignore it. Expect French users to re-config. This would be a regression.

Real, tested code does exist for this appraoch in the hedgewars-draft repo, but nemo has hidden the commits. Code is now very old and probably would needs a rewrite anyway.

Summary: This solution works (I have tested it). The only problem is with default config which would be less universal than our current approach, but this might be solvable.

=== D) Marry frontend with engine and only use SDL calls for all things keyboard ===

Criteria:

 * Would likely solve all problems

But this is a very very huge task, should not be done before 1.0 or otherwise we'd never get the 1.0 out