ScrollContainerWidget already reports child absolute positions with the current scroll offset applied through getChildX() and getChildY().
Do not add the scroll offset again when converting mouse down/up events to child-local coordinates. This keeps controls in scrolled containers, such as keymapper rows, clickable after the view has been scrolled.
The OptionsContainerWidget is a bare container without any graphical
existence. By making it inheriting the clipping rectangle from its boss,
this avoids clipping issues on checkboxes which slightly stick out from
their expected size.
When displaying or hiding a tooltip, just render them on the screen
buffer and redraw the underneath foreground dialog.
For this, the tooltip is detached from the usual dialog stack and is
treated as a special case.
The mouse can end up outside of the tray when scrolling and the just
clicked game has a short name.
Instead, register the case and close the tray only when mouse ended up
in it and left again.
Fix#16688.
This fixes a regression introduced in 441f97f4e4 (Implement drag to
scroll in ScrollContainer). The computation of the X and Y location
in the child when forwarding mouse down and up events assumed that
that child was a direct child of the ScrollContainerWidget (i.e.
that the child getRelX() and getRelY() are the position relative
to the ScrollContainerWidget). That caused incorrect x and y for
children of children.
One place where this could be seen are the custom game options
(Game tab of the Game Options dialog).
This commit fixes the issue by computing the relative position
of the child to the ScrollContainerWidget from their respective
absolute location).
Historically, we should the version build date wherever we display
the current ScummVM version.
However, this leads to issues with toolchains that care about reproducible
builds and thus set "fake" timestamps, e.g.
https://github.com/flathub/org.scummvm.ScummVM/pull/60#issuecomment-4150167445
Since we can derive the approximate release date based on our
new versioning scheme, it makes sense to hide the build date
from release builds and only use it for development builds
to keep track of "old" and "new" builds.