Resolving it when constructing the text widget may be too early for
widgets not defined in XML (like Android options widget).
This makes the alignment being invalid some times and valid some other
times.
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.
This should address the #13106 issue and similar
It makes widgets, who don't implement handleMouseWheel(), call the handleMouseWheel() of their parent by default
Logic is borrowed from how widgets forward unhandle commands to their parent in handleCommand()
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.