Follow-up Comment #1, bug #20251 (project wesnoth):
I noticed this problem too, and did some digging. The problem is that there
is some confusion when to use the character typed, and when to use the
keycode. I have a patch that fixes this problem.
svn diff src/hotkeys.cpp
Index:
Follow-up Comment #1, bug #20249 (project wesnoth):
While trying to figure out why CTRL+SPACE wasn't working, I found another
problem which could be causing this. The method get_hotkey() is being used
inconsistently, swapping ctrl and alt in places. Here's a patch showing the
problem.
Index:
Additional Item Attachment, bug #20208 (project wesnoth):
File name: ЛВ-Последний_оплот_эль..._повтор.gz
Size:113 KB
___
Reply to this item at:
http://gna.org/bugs/?20208
___
Message sent
Follow-up Comment #2, bug #20251 (project wesnoth):
The patch does not fix numbers or other keys in combination with ctrl.
Perhaps a more general solution involves using keycodes whenever the ctrl
modifier is present, and removing the ascii conversion math. A quick test
shows this approach is
Follow-up Comment #3, bug #20251 (project wesnoth):
The hotkey definitions aren't being saved. There is an inverted null check in
the save() method.
svn diff src/hotkeys.cpp
Index: src/hotkeys.cpp
===
--- src/hotkeys.cpp
Follow-up Comment #2, bug #20249 (project wesnoth):
Yes, that is the swapping that occurred in r55543. The question is why was it
done. Should it be simply reverted, or is there some reason to change the
order of parameters? (That revision was logged with the message code
cleanups, so presumably
Follow-up Comment #2, bug #20245 (project wesnoth):
What's shown there actually is the [side]save_id=, which happens to be the
leader's id in case it wasn't specified. (So one can put something better
there by setting a save_id.)
If it changes due to another leader, then that's probably bad and
