# HG changeset patch
# User Wuzzy <almikes@aol.com>
# Date 1556192799 -7200
# Node ID 32c29d1293ea47af099ae99d06e911f1cbfe0f04
# Parent  e478f27e997608ff4220cfedad1a5c2bbf8c0472
Add ControlsRework.wiki

diff -r e478f27e9976 -r 32c29d1293ea ControlsRework.wiki
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/ControlsRework.wiki	Thu Apr 25 13:46:39 2019 +0200
@@ -0,0 +1,49 @@
+#summary Solutions for fixing bug 240 (frontend displays wrong key name)
+
+This wiki page is for documenting and analyzing possible solutions for [https://issues.hedgewars.org/show_bug.cgi?id=240 bug 240] that have been discussed before.
+
+## Criteria
+
+First, for a working solution, it should match these criteria:
+
+ 1. 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
+ 2. The key that is displayed in frontend must match the key that is saved in config file
+ 3. (optional) Engine is able to convert the code to human-readable text. It's not a bug if it's not possible, however
+ 4. Default key config works with MOST normal keyboards (100% perfect coverage not required as its unrealistic; owners of exotic keyboards are expected to reconfig)
+
+## Possible solutions
+
+### A) Use keycode in frontend and config file, use scancode in engine (current broken approach)
+   1. No.
+   2. Yes.
+   3. No.
+   4. 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 (nemo's suggestion)
+    1. Yes.
+    2. No obvious solution in sight. Maybe there is one?
+      * Possible 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
+    3. Yes. Convert scancode to keycode with SDL_GetKeyFromScancode
+    4. 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 (Wuzzy's suggestion)
+   1. Yes.
+   2. Yes.
+   3. Yes.
+   4. 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
+    * Would likely solve all problems
+    * But very very huge task, should not be done before 1.0 or otherwise we'd never get the 1.0 out