Keypresses affect the game window from the save menu
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
widelands |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
From menus that hide the game/editor, keypresses are often routed to the game/editor window in the background and then handled there normally, causing (usually unwanted) actions (e.g. pause/unpause game, regulate game speed, show minimap, show editor tools, etc). Whether this happens depends on which element is focussed, i.e., whether and how this element handles keys.
This works for example
- from the save menu if the focus is not on the edit box
- from the load menu in the editor
- from the map options menu in the editor if focus is on none of the edit boxes
Haven't checked what route the key handling takes to end up at the game/editor window.
On a related note: If a menu doesn't cover the whole window, mouse events might also get through to the window in the background. This might be okay for many things, but feels a bit weird for the map options menu in the editor for example.
Possible fixes:
1. Would it be enough (and feasible) to open the menus in modal mode? Is key/mouse handling automatically contained then?
2. The game/editor window could have some "state" variable indicating whether it is in background or not (and possibly other states). And depending on this state, key/mouse handling is suspended.
3. Deal with the handling in all the relevant the menus, but that seems to be the wrong way.
no longer affects: | widelands/build21 |
Changed in widelands: | |
milestone: | none → build21-rc1 |
In the editor, we also need to be able to paint underneath a window even if it is focused, so that has to be taken into account too when doing any design changes.