|
Thu 01 Dec 2011 03:27:11 PM UTC, comment #8:
see also bug #19084
|
Sat 05 Nov 2011 08:01:44 AM UTC, comment #7:
"Still I am not sure about the original bug.
I guess that one of the hotkey representations is broken for your setup,
independent from the gui problem and how the hotkeys are displayed to the user."
r51664 did end up fixing bug #15567, but the bug I experienced (#18868) suggests that anyone who uses windows with anything other than the qwerty keyboard (any other language really) will find that their hotkeys aren't moving to match the layout they selected.
Having looked at the code (this is a little complex for my current C++ skills), I'm getting the sense that there is no simple solution, Other than what I proposed in my previous post, plus some hack to fix #15565 and make ctrl+alt+m work on windows. (don't know if possible.)
If not one option would be using r51664, along with code added that used something other than SDL for key input only on Windows. (thought that would take time and might be a bad idea, I don't know)
|
Sat 05 Nov 2011 12:44:03 AM UTC, comment #6:
Sigurd, it sounds like a good idea to do that.
Still I am not sure about the original bug.
I guess that one of the hotkey representations is broken for your setup,
independent from the gui problem and how the hotkeys are displayed to the user.
|
Mon 31 Oct 2011 07:10:28 PM UTC, comment #5:
fendrin, anonymissiums:
With the shift +'s not working right;
Given that: When changing a hotkey in the game, it enters "shift + c" as "C"
and
That the comments in ln 400 hotkeys.cpp agree that this is the desired behavior, also indicating a desire not to break old peferences.
The patch I would write would merely change what default hotkeys are created in the preferences file when an existing preferences file cannot be found. Specificaly replacing all occurances of "shift + char" with just the proper character, except the special ones like "space".
Thus, new installs with new preferences would automatically get the correct behavior on the hotkeys in question; and comptablity with old preferences be maintained, with the user able to change the key if need be.
If you agree with that, I'll go ahead and right up a patch to do that.
|
Fri 28 Oct 2011 04:30:37 PM UTC, comment #4:
Tried purging the preferences, thnigs still are as in my last comment.
Checked with r51660, it is as you say.
The shift +'s not working right with a different keyboard layout are present in 1.9.9 and 1.8.6
|
Thu 27 Oct 2011 11:52:40 PM UTC, comment #3:
Sigurd: maybe try deleting (renaming...) you preferences file (are the keys saved there ? probably)
The alt+ctrl parts are another bug: bug #15567
In any case, the stuff must've been present before fendrin's modifications.
|
Thu 27 Oct 2011 06:26:50 PM UTC, comment #2:
reverting r51664 was a parital fix
the x's(one letters), alt +'s, crtl +'s work now
the shift +'s are still remaining in the qwerty spots
the alt+ctrl+r & alt+ctrl+m are not working at all.
if ":" is listed as just that (without a shift in the [hotkey] tag), it works right, if it is listed as shift+; it does not work right.
|
Thu 27 Oct 2011 02:45:21 PM UTC, comment #1:
Fix for bug #17323 reverted (r51664)
Since we have two cases how to handle hotkeys, one for simple ones like single key presses or modified ones with only shift involved and the more complicated ones, I would like to know if the more complicated ones like (ctrl+alt+w) respect the loyout remapping as well.
|
Thu 27 Oct 2011 05:51:27 AM UTC, original submission:
Previously, I could change the keyboard layout in Windows, and the hotkeys would be remapped as expected in Wesnoth. (I am using US-Dvorak in Windows)
Now, they are no longer remapped and instead remain in their qwerty keyboard layout positions.
|
Related Recipes:
Battle for Wesnoth - Bugs: bug #18868, Hotkeys now go by qwerty layout,...