This fixes bugs #24211, #24214, #24213, #24209, #19666, #23534.
The GUI1 components have been made window event aware and will redraw
themselves after a window event.
Otherwise they cannot use any of the dialogs and we cannot do
leader select when joining a game.
This commit also adds an "any_running" helper to plugins_manager.
Formerly, the option buttons at the bottom of the dialog were laid out
by redoing some math instead of tracking the dialog's menu position,
which is always valid (even when there is no menu!). I'm not entirely
sure why, but the math reprised here became bogus with the introduction
of top buttons in commit 045bda037d78056866bdd918b51708d44d2bf515 (for
the Add-ons Manager dialog), in particular for dialogs *not* using them
(such as the in-game Statistics dialog), even though the menu is still
laid out correctly.
So instead of reinventing the wheel, we really should just take the
menu's position and height as a baseline for the bottom option buttons.
At worst the height is 0, but the position is still within the dialog's
boundaries (but see below for an unsolved corner case).
This commit reverts commit f60ef98e275fd3d16733f7d5dfd7314920841fd5
(a.k.a. 69521000dc5c45f9745131ee13e76493e14fefaa in 1.12) that's part of
PR #263, because it turns out that the solution proposed there is only a
convenient workaround that solves a layout issue for a single dialog
(Statistics, see bug #22379) and introduces a new bug for another
(Add-ons Manager, see bug #22791).
Regardless of the cause for #22791, the approach put forward by this
commit is more consistent with best practice (laying out widgets from
top to bottom each row's geometry depending on the previous row's), so I
have decided to not look too much into it.
It should be noted that the layout of bottom option buttons breaks
entirely for dialogs missing a menu, both before and after the
introduction of top buttons. Currently there is no GUI1 dialog that
attempts to insert option buttons while lacking menu entries, so I'm not
too concerned about this bug (which affects 1.10 too!). Besides, some
day GUI1 is supposed to go the way of the dodo and stop bothering us
with its marvelous inflexibility and arcane logic.
This is the result of running this command in directory src/
find . -type f -exec sed -i 's/\(ERR.*\)\\n\"\;/\1\" << std::endl\;/g' '{}' \;
and carefully inspecting the results.
utils::wide_string was a std::vector<wchar_t>
On most unix systems, this is 32 bits wide, and therefore a UCS-4 encoding.
On windows however, wchar_t is 16 bits wide, and the naive approach results
in UCS-2, which can only represent the Basic Multilingual Plane.
Most functions that used wide_string have been moved over to ucs4_string.
The Win32 API has been moved over to a specially created utf16_string instead.
Specialty tolower #ifdefs have been removed, as the towlower function has
been available since OS X 10.3, OpenBSD 3.7 and probably ancient versions of
all other BSDs too. The only issue is that on windows, the function cannot
be applied to characters outside the BMP.
When there's only one button with this hint, and there's a textbox, try
to align the button to the textbox. This makes the Filter/View Mode row
in the Add-ons Manager dialog look tidier.
This allows placing a button at the top-right corner in a stock gui1
dialog.
This implementation might not be bug-free (has only been tested against
the Add-ons Manager dialog for now), but it works and doesn't introduce
or fix bugs in other current dialogs.
