Avoid double-firing of keyPressed events
#2757
Conversation
The `IngameKeyListener` seems to double fire `keyPressed` events. The net effect is that it is impossible to use hotkeys such as 'B' because the dropdown construction menu just flashes for an instant and then closes back down immediately. I suspect this is a deeper issue inside `fifengine`, but I am not familiar with that so here I offer a quick fix to avoid the problem. Simply put, the `IngameKeyListener` keeps track of the last event and, if the current one is identical (same key, same press/release status), it directly discards it without further processing. Furthermore, I also cache an instance of `KeyConfig` inside `IngameKeyListener` instead of instantiating one every time `keyPressed` or `keyReleased` are called. This just popped to my eyes as an obvious optimization to implement, but feel free to discard if it gives raise to some problems.
|
Here is the associated issue: #2758 |
|
@helios2000 could it be an fife/fifechan problem? @FedericoStra Thank you for this pr :) First we will took on the issue whats going on. |
|
@AndyMender could you maybe review this please? :) |
|
Looks alright to me, but I too lack discrete knowledge on how Unknown Horizons handles key presses. @FedericoStra if you don't mind, we'll hold back with merging for now as our test server is in a shamble and many of the tests fail even locally. I would like to address that first. |
|
Bumping. @FedericoStra did you test that your patch addresses the issue you experience? I tried reproducing your problem, but for me the build menu works fine (appears after pressing 'B' once and disappears after pressing 'B' a second time). In principle, I can merge this, though sadly I cannot reproduce your bug :(. |
The
IngameKeyListenerseems to double firekeyPressedevents.The net effect is that it is impossible to use hotkeys such as 'B'
because the dropdown construction menu just flashes for an instant
and then closes back down immediately.
I suspect this is a deeper issue inside
fifengine, but I am notfamiliar with that so here I offer a quick fix to avoid the problem.
Simply put, the
IngameKeyListenerkeeps track of the last eventand, if the current one is identical (same key, same press/release
status), it directly discards it without further processing.
Furthermore, I also cache an instance of
KeyConfiginsideIngameKeyListenerinstead of instantiating one every timekeyPressedorkeyReleasedare called. This just popped to my eyesas an obvious optimization to implement, but feel free to discard if
it gives raise to some problems.