changeset 1852 32c29d1293ea
child 1853 f8b313ab3417
equal deleted inserted replaced
1851:e478f27e9976 1852:32c29d1293ea
     1 #summary Solutions for fixing bug 240 (frontend displays wrong key name)
     3 This wiki page is for documenting and analyzing possible solutions for [ bug 240] that have been discussed before.
     5 ## Criteria
     7 First, for a working solution, it should match these criteria:
     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
    10  2. 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
    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)
    14 ## Possible solutions
    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
    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)
    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       *
    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.
    34 ### C) Use keycodes in frontend, config und engine (Wuzzy's suggestion)
    35    1. Yes.
    36    2. Yes.
    37    3. 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.
    47 ### D) Marry frontend with engine and only use SDL calls for all things keyboard
    48     * Would likely solve all problems
    49     * But very very huge task, should not be done before 1.0 or otherwise we'd never get the 1.0 out