4 |
4 |
5 ## Criteria |
5 ## Criteria |
6 |
6 |
7 First, for a working solution, it should match these criteria: |
7 First, for a working solution, it should match these criteria: |
8 |
8 |
9 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 |
9 # 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 |
10 2. The key that is displayed in frontend must match the key that is saved in config file |
10 # The key that is displayed in frontend must match the key that is saved in config file |
11 3. (optional) Engine is able to convert the code to human-readable text. It's not a bug if it's not possible, however |
11 # (optional) Engine is able to convert the code to human-readable text. It's not a bug if it's not possible, however |
12 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) |
12 # Default key config works with MOST normal keyboards (100% perfect coverage not required as its unrealistic; owners of exotic keyboards are expected to reconfig) |
13 |
13 |
14 ## Possible solutions |
14 ## Possible solutions |
15 |
15 |
16 ### A) Use keycode in frontend and config file, use scancode in engine (current broken approach) |
16 === A) Use keycode in frontend and config file, use scancode in engine (current broken approach) === |
17 1. No. |
|
18 2. Yes. |
|
19 3. No. |
|
20 4. Yes. |
|
21 * 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 |
|
22 |
17 |
23 ### 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) |
18 Criteria: |
24 1. Yes. |
|
25 2. No obvious solution in sight. Maybe there is one? |
|
26 * Possible solution: Convert scancode to keycode using a hardcoded lookup table or something like that |
|
27 * https://github.com/hluk/qxtglobalshortcut/blob/16446200b699e0610b8a5fb20b74938225d81d87/src/xcbkeyboard.h#L249 |
|
28 3. Yes. Convert scancode to keycode with SDL_GetKeyFromScancode |
|
29 4. No idea. |
|
30 * Note: Adding a new program only to grab the key seems a little insane, but it seems to work |
|
31 * Note: We have a mock-up of the keygrab program, but no code for the rest exists yet |
|
32 * 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. |
|
33 |
19 |
34 ### C) Use keycodes in frontend, config und engine (Wuzzy's suggestion) |
20 # No. |
35 1. Yes. |
21 # Yes. |
36 2. Yes. |
22 # No. |
37 3. Yes. |
23 # Yes. |
38 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. |
|
39 * Possible solutions for 4) |
|
40 * Allow numpad numbers as alternative input for timer keys |
|
41 * Implement user-selectable alternative keys for everything and add numpad keys as alternative input for timer by default |
|
42 * When detecting French keyboard on first launch, use different default keys (does not sound very stable ... Also, how to detect keyboard layout in Qt?) |
|
43 * Non-solution: Ignore it. Expect French users to re-config. This would be a regression. |
|
44 * 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. |
|
45 * 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. |
|
46 |
24 |
47 ### D) Marry frontend with engine and only use SDL calls for all things keyboard |
25 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 |
48 * Would likely solve all problems |
26 |
49 * But very very huge task, should not be done before 1.0 or otherwise we'd never get the 1.0 out |
27 === B) Use scancodes in frontend, engine und config. Crate a small helper program that queries scancode in frontend to replace the drop-down menu === |
|
28 # Yes. |
|
29 # No obvious solution in sight. Maybe there is one? |
|
30 * Possible, hacky solution: Convert scancode to keycode using a hardcoded lookup table or something like that |
|
31 * https://github.com/hluk/qxtglobalshortcut/blob/16446200b699e0610b8a5fb20b74938225d81d87/src/xcbkeyboard.h#L249 |
|
32 # Yes. Convert scancode to keycode with SDL_GetKeyFromScancode |
|
33 # No idea. |
|
34 |
|
35 * Note: Adding a new program only to grab the key seems a little insane, but it seems to work |
|
36 * Note: We have a mock-up of the keygrab program, but no code for the rest exists yet |
|
37 |
|
38 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. |
|
39 |
|
40 === C) Use keycodes in frontend, config und engine === |
|
41 |
|
42 Criteria: |
|
43 |
|
44 # Yes. |
|
45 # Yes. |
|
46 # Yes. |
|
47 # 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. |
|
48 |
|
49 Possible solutions for 4) |
|
50 * Allow numpad numbers as alternative input for timer keys |
|
51 * Implement user-selectable alternative keys for everything and add numpad keys as alternative input for timer by default |
|
52 * When detecting French keyboard on first launch, use different default keys (does not sound very stable ... Also, how to detect keyboard layout in Qt?) |
|
53 * Non-solution: Ignore it. Expect French users to re-config. This would be a regression. |
|
54 |
|
55 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. |
|
56 |
|
57 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. |
|
58 |
|
59 === D) Marry frontend with engine and only use SDL calls for all things keyboard === |
|
60 |
|
61 Criteria: |
|
62 |
|
63 * Would likely solve all problems |
|
64 |
|
65 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 |