By implementing MetaEngine::buildEngineOptionsWidget, engines can
instantiate a container widget that will be shown in the Engine tab of
the edit game dialog. The default implementation retains the existing
behavior and shows the extra GUI options.
Prior to this change, a GUI layout was only affected by the screen size.
Now, a layout can additionally be influenced by the GUI dialog and widgets
that uses it. This capability is leveraged to implement the following
features:
* Layout elements that are not bound to a GUI widget do not take space.
This means that dialogs where the widgets shown depend on for example
a feature being enabled at configure time no longer have blank spaces.
* Widgets can define a minimal required size for their contents not to be
cut. For now this is only used for buttons so their width is always
sufficient for their caption not to be cut. This mechanism could be
applied to other widget types in the future.
Selecting whether a clipping variant of a draw call needs to be used is
no longer the responsibility to the caller. The clipping rect is now
part of the state of the renderer.
Also fix some of the draw calls to better apply the clipping rect.
Drawing nows happens directly when the Dialog or Widget draw methods are
called. This makes it easy to debug why a particular low level draw
method was called, by inspecting the call stack.
This replaces the notion of "buffering" by two independant ways to
control what is drawn and where:
- The active layer is used to select whether the foreground or
background part of the dialogs are rendered by the draw calls.
- The active surface is used to select if the draw calls affect the back
buffer or the screen.
The foreground layer of the active dialog is drawn directly to the
screen. Its background layer is drawn to the back buffer. This way
widgets can restore the back buffer in order to update without having to
redraw the dialog's background.
Dialogs lower in the dialog stack are drawn entirely to the back buffer.
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
