Otherwise this situation gives the WML coder merely the message "Failed to load
the scenario", without any further hint about why. The tagname is printed in case
the scenario needs to be a [multiplayer] or a [test] instead of a [scenario].
This should extend the dialog's usefulness in a way that is more or less
consistent with the Add-ons Manager's search function. Although one
issue is that abbreviations are often found floating around in their
English form ("HttT") instead of the various localized versions ("HaT").
* Return paths from fs API in the native format, not the generic
format. The generic format looks wholly out of place on Windows.
* Move the versions selector to the row with the dialog caption and
Search box as per d53ca602b8df5cc302cd1d5d502654823dc67415.
* Relabel options to make the purpose of the combobox clearer even
without the tooltip.
* Fix markup not being taken into account for the combobox option
labels, and protect against potential markup characters in paths
(shouldn't happen on Windows but it can happen on POSIX platforms).
The original code by octalot only works correctly on X11 when using the
recommended fdo layout. Windows and macOS need their own logic to build
candidate paths.
The code is still very optimistic about this whole thing -- see the
comment. Ideally we need to refactor the system to determine user data
path defaults so we can do it as many times as necessary even if we've
already determined our current user data path, but that seems like a lot
of work for a worst-case scenario that's not gonna crop up very often.
Also, I have no idea if the macOS alternative works, or what will happen
on iOS for that matter. It should at least compile.
This is very configuration-specific and only seems to happen on Windows
at the moment, which is kind of intentional from what when I discussed
the code with josteph.
Credit to @shikadiqueen for the idea. This fixes potential crashes if the padding can't fit on certain resolutions.
Also keeps the vertical spread consistent between resolutions (no more < 800 height handling).
We're going to be using NN scaling for the map, and that's already handled automatically
by SDL (and in the future, OGL). We don't need these settings for surface SCALED_TO_ZOOM
and SCALED_TO_HEX scaling. In any case, if we want to scale a surface to zoom or hex, it
will almost certainly be for map rendering (such scaling methods don't make sense in the
UI, for example), so just defaulting to NN is simplest.
This change drops the option to use Linear or xBRZ scaling for map zooming. This was already
the practical case due to me converting map rendering to use textures. NN was used for all
zoom levels, and it's fast and looks good.
Several dialogs have Search boxes accompanying a central element, with
the boxes taking up a whole row of their own. For both aesthetic and
space allocation purposes it turns out to be more convenient to relocate
these boxes to the top right corner of the dialog to share room with the
dialog's caption.
This only applies to the Campaigns menu, Load Game, Create Unit, and
Recall Unit dialogs. The Recruit Unit dialog, interestingly enough,
already used this approach (an accident?).
Chat Log and the Add-ons Manager *could*, in theory, use this same
change, but they are a bit trickier because of the additional controls
attached to the Search box -- especially so in the Add-ons Manager's
case.
[ci skip]
