The issue was with the focus or mouse widget as it may not be a
direct child of the dialog (it may for example be a child of the tab
widget in the options dialog) and removing a widget was not
resetting the mouse of focus widget if that widget was not a
direct child.
Previously, they only reacted to the mouse position once it was moved.
This meant that if the cursor was on a button that just gained focus,
it did not highlight.
Fixes#7101.
This means x and y has the same meaning as in the other handlers,
e.g. handleMouseUp(). Though as far as I can tell, these coordinates
aren't actually used anywhere at the moment.
Because the "clear" buttons are very different between themes (in
the Modern theme they have a graphical symbol, while in the Classic
theme they have a letter), they have to be removed and re-added
when reflowing the layout. This is patterned after how the
LauncherDialog class handles the larger changes in layout.
Removing widgets from a tab turned out to be trickier than I first
thought, so I had to move the removeWidget() method from Dialog to
GuiObject.
This because theoretically the GUI could be run without a dialog.
This also fixes the situations where the GUI keymap gets popped more times than pushed.
Thanks sev
This fixes a problem where opening the keymapper dialog would cause the current game
keymap to be displayed as the active keymap but then changing the keymap selection
back to it would cause the GUI keymap to be displayed as the active one. The GUI keymap
was indeed at the top of the stack but that's not the desired effect.
Also move the pushing and popping of the keymap to Dialog::Open/Close
Also constantify the GUI keymap name
- Merge is perfromed in order to not let rotting the code
- Makefile modifications were avoided
Stuff to resolve:
- Circular dependency of common/vkeybd from graphics/
- Make it compilable (?)
- Add some keyboards
- Decide on the key bindings
svn-id: r35813
* Moved the code which handles fallback to the built-in theme from ThemeEngine to GuiManager
* Changed ThemeEngine::init() to only init&load the theme; no more messing with the overlay
* Commented to a somewhat obscure line in the GuiManager event loop (taking eriktorbjorn's original commit message for that change as comment text)
* Cleaned up the way the Dialog constructor ensures that the current Theme is correctly setup
* Got rid of varios members of ThemeEngine
* Changed ThemeEngine members _screen and _backBuffer from Surface pointers to just plain Surfaces
* Changed ThemeEngine::loadFontFromArchive to use _themeArchive instead of creating an Archive from scratch
* Renamed ThemeEngine::getThemeFileName() to getThemeId() (and some associated tweaks)
* Lots of further cleanup and tweaks
svn-id: r35653
