# HG changeset patch # User Wuzzy # Date 1556192993 -3600 # Node ID f8b313ab3417d51437ff53ed808420646018a740 # Parent 32c29d1293ea47af099ae99d06e911f1cbfe0f04 ControlsRework: Reformat page diff -r 32c29d1293ea -r f8b313ab3417 ControlsRework.wiki --- 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