Instead of having the preferences dialog make a copy of all advanced preference config objects (and sorting them)
every time you invoke it, this adds a new advanced_manager class instantiated once in game_launcher (not sure if
that's the best place for it, though) that parses and handles the options. Allows me to greatly clean up the
preferences dialog code.
Back when link awareness was first added (https://github.com/wesnoth/wesnoth/pull/300), this key was added
globally to label definitions alongside link_color. This had the unintended side effect of making *all* labels
link aware, leading to issues such as being able to open a do-you-want-to-open prompt from an instance of the
same ad-infinitum.
This became an active issue after 213453e6cf78371360471ac4d110602aafecd9f3, since now that labels could capture
focus if link_aware was true - which it always was for most labels - labels in toggle panels would always
grab mouse_motion events and no longer allow their parent toggle panels to gain their hovered states. That
appears to be in keeping with the design of GUI2, and a further evaluation of that issue is needed at a later
time. However, the fact remains that almost every single label was marked as link-aware, even when in almost every
case that was not the desired behavior.
This change move the link_aware config option to individual label and scroll_label instances. The following uses
had this explicitly enabled:
- Addon license prompt
- Addon descriptions
- Campaign descriptions
- The Server Info popup
- The chatbox
Previously, I was handling updating the label alpha in the set_text_alpha function, which meant it needed
to be called from the builder in order for that variable to be properly set on a newly constructed label.
This properly adds it to the update_canvas and changes set_text_alpha to match the other setter formats
that require canvas updates.
This also moves gui2:🏷️:can_mouse_focus()'s declaration to a
section that makes more sense for it to be in. Thanks to jyrkive for
pointing out the existence of this method.
The code in both is almost identical except for the check for .pbl
files. Furthermore, the call to filesystem::get_files_in_dir() does not
need a list of files to output since support for Addon_Name.cfg-style
add-ons was dropped in version 1.13.0.
The ADDON_ENUM_CRITERIA enumeration is there in case in the future we
need more criteria for enumerating add-ons. Right now it's just a
convenience so enumerate_addons_internal() takes a self-descriptive
parameter instead of a boolean.
Since write_addon_install_info() (which was just added) automatically
wraps the input in the [info] envelope, it make sense to me to do the
inverse operation in get_addon_install_info() as well instead of
off-loading the responsibility onto the callers. The file in question
should never contain any useful information outside of the singular
[info] node anyway.
(Admittedly, this obsoletes the previous bugfix in
220792dd07b525c9b925c8fdb811b3661578dd64. On the other hand, it was
useful to have it in that form in 1.14 anyway to avoid any accidental
regressions.)
Quite concerningly, people made a typo ('proscribed' instead of
'prescribed') which changes the meaning of the sentence in question
rather substantially.
Additionally, the situation with different versions of the GNU GPL
hasn't ever been quite clear -- in theory people could've used the GNU
GPL version 1 with content previously licensed under version 2 or later.
This change is meant to address this issue as well. Some redundant
wording has been removed in the process.
(Reviewed by Pentarctagon and Vultraz.)
Fixes the dreaded "Mandatory WML child missing yet untested for. Please
report" error occurring when reading _info.cfg files that don't have a
valid [info] tag. In particular, this would cause the game version
dialog to crash to desktop.
This reduces code duplication in the client proper resulting from the
addition of delta pack support, plus makes the overall procedure less
complicated since we don't have to inject a file into the pack before
unpacking it to disk.