Reverts the second portion of 95bcf34133e84d1333301d81b640f447553f6820
in a way (we still want it on a new line) for consistency with commit
996b31def547be7a093b699ec84c0581208308b9.
The optional argument allows us to specify a nicer and more relevant
position message format for the two parser errors that involve more than
one file location: missing closing tags (expected location and opening
location) and invalid closing tags (opening location and (invalid)
closing location).
This makes it easier to tell what's going on even when confronted with a
kilometric preprocessor brace-substitution trail, e.g:
> Found invalid closing tag [/tag2] for tag [tag1]
> Opened at ~add-ons/My_Add-on/scenarios/24.cfg:1090
> included from ~add-ons/My_Add-on/scenarios/24.cfg:120
> included from ~add-ons/My_Add-on/_main.cfg:42
> [...]
> Closed at ~add-ons/My_Add-on/scenarios/24.cfg:1098
> included from ~add-ons/My_Add-on/scenarios/24.cfg:120
> included from ~add-ons/My_Add-on/_main.cfg:42
> [...]
Some day we will be able to make it easier to handle these situations by
ensuring the trail format is concise and relevant, but that day will not
come before 1.13.0. Messing further with the main ::lineno_string()
function (in preprocessor.cpp) would be risky at this point with 1.12.0
approaching.
Passing translated strings instead of translatable strings makes a bunch
of things easier:
* We don't need to worry about forgetting to call gettext _() in
lineno_string() (which, as a matter of fact, I forgot to do for
hint_string, oops)
* We can append and preprend stuff to the *translated* strings before
passing to lineno_string() without breaking localization! Woo!
Using STL strings instead of C strings also makes things easier and
prettier. The negligible performance impact shouldn't be a concern here
because landing in parser::lineno_string() or parser::error() is a
worst-case situation since it only happens when the parser encounters an
error and cannot continue.
Also, parser::lineno_string() now takes an optional fifth argument
with the tokenizer state message to append to the end of the full
message and trail. We need that for the next commit.
Note that this widget lacked a background before, making it look like
a simple label with a border and caret. In my opinion, the subtle
background is an improvement that highlights the widget's "dynamicness",
and makes it more obvious when it is disabled.
Turns out there already was a somewhat more elegant solution in use for
the GUI2 lobby and macroified for everyone else. It uses a
stacked_widget with a spacer within instead of the awkward 2x2
{[central widget,spacer],[spacer,spacer]} grid we were using here.
Replace the definition of GUI__BACKGROUND_COLOR_ENABLED (used by the
"listbox_text" and "listbox_text_with_icon" variations of
ttoggle_button, and the default ttoggle_panel variation) so that it
matches the gui::menu::bluebg_style GUI1 menu style definition in
src/widgets/menu_style.cpp:29.
These controls are commonly used with gui2::tlistbox, so this change is
intended to make GUI2 listboxes in general have the same overall
appearance as GUI1 menus after the dialog background graphics were
replaced as part of the UI overhaul in 1.11.x.
The previous background definition for these GUI2 widgets was a solid
color, rgb(21, 19, 19), meaning that they necessarily wouldn't match
the standard bluebg_style GUI1 menu style, which uses rgba(0, 0, 0,
0.35).
Alpha 255 * 0.35 = 89.25, hence the new definition of
GUI__BACKGROUND_COLOR_ENABLED has an alpha channel value of 89 and not a
multiply of 10 or 2 like 90.
When pressing the next or previous tip button there is a drawing glitch.
As soon as the mouse pointer leaves the button area the glitch
disappears. For now force an update directly after the button is
pressed. This is not particularly elegant, but it works. The SDL2
transition will probably fix this issue automatically.
Shadowm figured out why blurring didn't work properly in the title screen
and created a proof-of-concept patch. This patch is heavily based upon
that patch.
When the main screen and in turn caused the minimap to resize this change
was not propagated to the minimap until one of the minimap view buttons
was pressed.
This fixes a part of bug #21584.
This change to the ThemeWML will avoid the offmap drawing issues due to
accidentaly changing or removing the main_map_border section from a
resolution. If it is really wanted it is possible to add an id to this
section, the game doesn't use it, but inheritance uses the raw config.
This fix rewrites the expand_partialresolution, adding the check and
making the code easier to follow.
This should avoid bugs like bug #21584.
The problem was a bit tricky. A partial resolution removed an element with
an empty id. The main_map_border section has no id and thus an empty id.
So the inheritance removed this section by accident. Of course the id for
a removal or change should be mandatory, which the next patch will do.
This fixes a part of bug #21584.
Take about 40% of the villages off the map and change the paths in the
southeastern part of the map a little. The latter is done so that the
eastern enemy focuses more on Kapou’e rather than the southeastern
ally, making the AI leader surviving less dependent on luck.
Because this window many contain a lot of text in both directions,
having it change size dynamically every time the log page is switched or
a new text filter is entered can be extremely annoying for the player.
Setting the scroll_label's parent (now ancestor) cell's minimum size to
something that isn't 0x0 mitigates the issue to some extent. Better than
nothing, I guess.
(Tested with a screen resolution of 800x480.)
