SDL_GetKeyState is called from mouse event handlers

[Sigra]

SDL_GetKeyState is called (via bool WLApplication::get_key_state(SDLKey) and bool UI::Panel::get_key_state(SDLKey)) from mouse event handlers to get the state of modifier keys (Ctrl, Alt, Shift, ...). This is erroneous because it will get the current state, not the state when the mouse event occurred. Unfortunately the needed information is not available in mouse events, which is "a huge oversight" in SDL 1.2. A fix is promised in SDL 1.3 (see [http://lists.libsdl.org/pipermail/sdl-libsdl.org/2008-March/064560.html]).

[Nicolai Hähnle (nha)]

Logged In: YES
user_id=211820
Originator: NO

Now that I thought about this some more, it's actually totally incorrect for us to call SDL_GetKeyState at any time, because it breaks the record/playback system.

So we should probably just maintain our own key state array which does the right thing. (Alternatively, the behaviour of calling SDL_GetKeyState could be fixed wrt record/playback by intercepting those calls like we do in get_time())

[SirVer (sirver)]

I am currently wrestling with this issue again as I want to be able to set/unset modifier keys via scripting, so that I can more closely simulate user input for testing in the editor.

I was unable to find the message linked in the OP, seems like it is gone. Nevertheless, I think I will just implement a basic array that keeps track of some of the special keys that we use, likely in wlapplication. What do others think?

[SirVer (sirver)]

Just as I posted this, I found the old thread: http://lists.libsdl.org/pipermail/sdl-libsdl.org/2008-March/064377.html... I do not see the difference to the OP link, but this one works.

[Nicolai Hähnle (nha)]

I think the approach of keeping track of this manually in wlapplication is fine.

[SirVer (sirver)]

Setting to incomplete for bug sweeping.

[Launchpad Janitor (janitor)]

[Expired for widelands because there has been no activity for 60 days.]

[SirVer (sirver)]

I am no longer concerned about this. SDL2 fixes this issue and our switch is imminent. Also, the record and playback functionality has been removed as it was no longer useful, so the underlying issue is not that big of a deal for the logic anyways anymore.