This fixes bug #14404.
The rercusive call was introduced with commit 325260f that changed
the implementation of Widget::handleMouseWheel to call handleMouseWheel
on the widget boss. If the widget boss is a dialog, its implementation
is to call handleMouseWheel on the widget under the cursor. And
we can end up with an infinite loop.
As indicated in bug #13106, which was fixed by commit 325260f, a
similar infinite loop when using the mouse wheel to scroll tabs in
the options dialog was caused by the commit and quickly fixed. But
the fix was only for that particular case. Here the fix should
be more global.
The resize() function has the option to do the scaling, but
adding it to the construtor avoids having to then call resize().
Also this makes more explicit that by default the sizes are not
scaled. The reason for not scaling by default is because values
with get from the ThemeEngine are already scaled.
The tooltip will show only if mouse cursor was moved but not on a hovered focused editText field
Changes and implications in this commit:
- Fix _lastMousePosition coordinates and time being updated upon giving focus to the tooltip
- Check for mouse cursor movement first in the decision for showing the tooltip, then check if sufficient time for mouse resting position has passed (kTooltipDelay).
- Prevents showing a tooltip for a widget if it is an editable field (editText) and has both mouse hovering above it and the current focus.
This is so that typing text is not interrupted / slowed down by a periodical display of the tooltip, if the mouse is hovering over the same text field that the user is editing.
- If mouse cursor is moved but lands on the same widget as the one that had its tooltip shown last, then show the tooltip but after a different (larger) delay kTooltipSameWidgetDelay.
- Still shows tooltip for other widgets, including editText ones, if the mouse is hovered over them and they are not the current focused editText widget.
The bug was mentioned for the Android port on the forums here:
https://forums.scummvm.org/viewtopic.php?p=95531#p95531
However, it is not Android specific, even though the slowdown is a lot more noticeable on an Android device.
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
