Ports can add additional special keys.
SDL no longer carries the static tables.
Default behavior unchanged: HardwareInputSet() still gives an empty one.
This makes it so that there's 2 groups:
1 - The keymap stack
2 - The loaded keymaps
The first group displays which keymaps are active and which keymaps
are completely blocked due to an opaque keymap on top.
The second group displays which loaded keymaps store their mappings
globally and which ones store their mappings per-target.
find -name '*.h' -or -name '*.cpp' | xargs sed -r -i 's@\(([A-Za-z0-9]+)\*\)@(\1 *)@g'
This seems to have caught some params as well which is not undesirable IMO.
It also caught some strings containing this which is undesirable so I
excluded them manually. (engines/sci/engine/kernel_tables.h)
Re-selecting the top entry would always populate the actions
from the GUI keymap since it is the active keymap (the remap
dialog itself is GUI)
The top keymap was correct during RemapDialog::open() because
the gui keymap had not been pushed to the stack yet.
This should make it clear what keymaps are on the stack and in
what order.
Also renamed the label of the top "special" entry in the list to
"(Effective)" since it displays the top keymap's action and also
displays reachable mapped actions from other active keymaps.
The == operator in KeyState should not be checking for sticky modifier
keys. This allows the keymapper's defined actions to function correctly
in desktop platforms, when sticky modifier keys such as caps lock and
num lock are turned on. Also, added some sanity checks to hasFlags()
and enums for sticky and non-sticky keys
This is because the top GUI keymap is for the keymapper dialog itself.
If all GUI keymaps are skipped then when inside a game with the GMM displayed
and the keymapper dialog invoked, the game keymap is displayed even though it
is not the active one.
This fixes a problem where opening the keymapper dialog would cause the current game
keymap to be displayed as the active keymap but then changing the keymap selection
back to it would cause the GUI keymap to be displayed as the active one. The GUI keymap
was indeed at the top of the stack but that's not the desired effect.
Also move the pushing and popping of the keymap to Dialog::Open/Close
Also constantify the GUI keymap name