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.
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.
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.)
The macro-less portions of these terrain graphics rules are now the
TRASH_A and LITTER_BASE macros. I tried to the best of my ability to
understand how they are supposed to work together, so this is the naming
scheme and parameter set I found to be the most optimal:
#define TRASH_A TERRAIN PROB IMAGESTEM
Covers the first and second rules, which are used on a single
terrain pattern.
#define LITTER_BASE TERRAIN IMAGESTEM
Covers the third rule, which affects both trash terrains.
Since the GUI2 titlescreen took over, the path to tips.cfg is not
hard-coded in the engine anymore; in fact, this commit also updates that
path, which is in data/gui/default.cfg.
This allows us to be more self-contained and require less logic in the
instantiation site for preparing the report for display.
This requires adding a new row and label for displaying the list of
faulty files, which will be hidden when the list is empty or not
provided in the display() static member function.
This dialog features separate summary and detail sections along with a
small heading for the latter in bold face. More features may be added
later as part of my work on improving WML diagnostics, but for now we
have the bare minimum for better message formatting with a content
structure more or less identical to the current one.
The scenario author now has the option to use either the default AI
[avoid] tag or a specialized [avoid] tag inside the [micro_ai] tag. If
neither is given, the default remains all castle terrain.
If [filter_second] is not given, sighted events are now triggered by
_any_ side. We need to figure out whether this is a bug or intended
behavior. If the latter, all sighted events in mainline campaigns need
to be checked.
Fixes the somewhat unlikely situation of him clobbering whichever unit
happens to be standing on 31,11 and causing it to disappear from the
game forever (especially bad if it's a player unit).
This commit is dedicated to my loyal Knight Haldiel, who became victim
to this oversight.
The placement of tooltip is controlled by the WML of the GUI engine. The
code is not used yet, only available with a proof-of-concept define named
DEBUG_TOOLTIP.
