This is a blanket fix for the issue I previously tried to fix for
specific cases in the following two commits:
* 1df73b9e4c Call display::draw() before setting theme UI button states
* f93b439e13 Call set_button_state() from playsingle_controller::init_gui()
This final version of the fix is far superior as it doesn't involve
sloppy guesswork regarding the various display class redraw methods and
their call sites. Instead, we just copy the previous state for each
button during reconstruction regardless of the situation at hand. We
know they are the right buttons because they have the same id strings.
It is a little more involved than I would've liked because it has to
deal with a quirk in gui::button's implementation that becomes more
evident with this fix. The following primarily applies to
gui::button::load_images():
gui::button generates its own built-in image size filename suffix for
the button overlays and frames when the button dimensions are already
known, usually after a method call that sets the button's geometry with
a valid size (i.e. not -1234 x -1234). button::set_overlay() happens to
be such a method, but not all buttons use it to set their initial
overlay, and that's where trouble begins...
* Some theme UI buttons (mostly in the editor, and the Draw Terrains
and Draw Units toggles on the minimap area in-game) have their
overlay icon paths set in the WML, including their _25 size suffix.
These have their overlays (and frames) set initially set by the
gui::button ctor, which loads the images and figures out the button
dimensions in the process (via button::load_images()). The ctor
always does this unconditionally.
* At that time, button::load_images() will not add an engine-defined
suffix because the button dimensions are still unknown until it
finishes. The images are loaded successfully.
* Subsequent calls to button::set_overlay() *with the same path* will
have button::load_images() append its own suffix determined from the
previously determined button dimensions. Hilarity ensues.
The hotkeys engine (via hotkey::command_executor::set_button_state())
and the theme WML have different notions of which button icons have a
suffix defined externally to gui::button. This results in situations
where restoring the previous icons in display::create_buttons() causes
gui::button to look for inexistent images with duplicate size suffixes
("_25_25"). Although modifying the mainline WML to avoid using those
suffixes in the first place would be the most elegant solution, it also
has the potential to cause issues with UMC themes (esp. forks of the
mainine themes), even if those are relatively rare. Moreover, it counts
as a violation of the stable branch ban on API changes.
In other words, even if this part of the fix is very ugly, it's
ultimately necessary if we are to fix the original bug in a stable
branch without breaking the theme WML API contract. This is also why
everything is in a single commit instead of split in two.
Also note that the aforementioned commits aren't fully obsolete; the
most recent one is actually still required so that the hotkeys engine
gets to set the button icon overlays at least once (for those buttons
which don't have this defined by WML) before running WML events. Any
redundancy arising from keeping them wouldn't hurt anyway.
Finally, all this has been rendered irrelevant in master by Aginor's
refactoring and bug fixes, so this code is a technological dead end
anyway.
boost::locale::generator::add_messages_domain() interprets the slash
specially, interpreting everything after it as an encoding name.
It's not clear to me why providing a textdomain with an erroneous name
like this causes Boost.Locale to throw a boost::locale::conv exception
(invalid_charset_error, apparently) when handling t_strings bound to
completely different textdomain, but if we can avoid the issue
altogether then that's good enough.
Made the legacy implementation skip and warn about these names too even
if bindtextdomain(3) says nothing about slashes having a meaning.
Due to an unfortunate combination of Cairo's use of premultiplied alpha
and our engine expecting to be able to blit pre-rasterized text surfaces
with an alpha channel into arbitrary surfaces, we can't safely use RGB
subpixel hinting without getting glyph color glitches. This is
particularly noticeable in GUI2 dialogs when the system fontconfig
settings dictate subpixel hinting to be enabled. Bug #21648 is just a
Windows-specific case of the same issue exacerbated by an as of yet
unaddressed peculiarity of Cairo's premultiplied alpha format on
Windows.
SDL_ttf avoids the issue entirely by always using an equivalent of
hintstyle=full and rgba=none with FreeType directly. There are very few
UI components in Wesnoth using SDL_ttf anymore, but they are still large
enough to make the rendering differences rather jarring (MP lobby,
preferences dialog, parts of the theme UI).
Our new custom fontconfig settings use hintstyle=full and rgba=none to
produce the same results with both SDL_ttf and Pango/Cairo render paths,
and eliminate the subpixel hinting glitches. This Works For Me™, but
fontconfig and Cairo generally seem unwilling to cooperate with me and
may produce different results on other systems.
It remains to be seen exactly how this patch impacts Apple OS X users
due to bugs #23560 and #23628. Windows users are unaffected and still
depend on the "fix" for #21648 because fontconfig is apparently disabled
for most intents and purposes on that particular platform (see also
commit cad8798d1a).
This function is implemented using case-insensitive pattern matching,
unlike filesystem::ends_with(). I missed this when writing my original
fix, so the vulnerability still applied to .pbl files on a
case-insensitive filesystem (e.g. NTFS and FAT* on Windows) by using
different case to bypass the check.
