--- a/ControlsRework.wiki	Thu Apr 25 13:46:39 2019 +0200
+++ b/ControlsRework.wiki	Thu Apr 25 12:49:53 2019 +0100
@@ -6,44 +6,60 @@
 
 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)
+ # 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)
 
 ## 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
+=== 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.
 
-### 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 ===
+
+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.
 
-### 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.
+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.
 
-### 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
+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