The current preferences handling is a mess:
* it's essentially a global config object that anything can modify in any way the caller wants, which is managed across multiple source files which have their own oddities and interdependencies.
* the general preferences has its own bit of SDL event handling and while I get the idea behind `events::sdl_handler` there's no reason to have SDL events handled in the preferences instead of just calling the relevant preferences setter for each event when it happens.
* the general preferences is where most of the preferences are handled and has its `base_manager` struct, which is part of the `manager` struct in the game preferences, which is then implicitly initialized as part of game_launcher's constructor.
* the editor preferences are the only preferences in a sub-namespace `preferences::editor` while all other preferences are just in the `preferences` namespace.
* the display, editor, and lobby preferences are all dependent on including the game preferences, the credentials are dependent on including the general preferences (but not the game preferences), the game preferences are dependent on including the general preferences, and the advanced preferences are entirely their own thing which is dependent on none of the other preference functionality and manages its own singleton.
* nothing checks whether the preferences file has actually been loaded before allowing values to be read from or written to the preferences config - if you attempt to get a value too early in wesnoth's initialization it will silently just give you whatever the default value for that preference happens to be.
With this there is instead a single access point (with exceptions handled via friend functions/classes), all predefined preferences are accessed via their own setter/getter, and all mainline preferences are defined in a single file (preference_list.hpp) so it's easily findable what preferences exist and where they're used. Having the list of all mainline preferences listed out also allows the lua preferences API to provide that full list rather than just the list of the preferences that have been set so far. Also it now checks for whether the location of the preferences file is known before attempting to load the preferences file and asserts if someone attempts to use the preferences too early.
Adds support for using these in the weapons and ability filters:
* "-1", which was previously treated as an parse error (no number before the separator).
* "-3--1"
* "-infinity" as the lower number in the range, provided a different upper number is given.
This treats "-infinity" (with no other number), "-infinity--infinity",
"infinity" (with no other number) and "infinity-infinity" as errors. It seems
unlikely that someone would intend to use a filter that can't match any
reasonable number.
The range "-infinity-infinity" will be parsed successfully. I don't see a use
case for that, but nor do I see a reason to add extra C++ to reject it.
However, it's not added to the schema, as I think it's good for the schema to
give a warning when someone creates a filter which will accept every value
(including accepting the default, so "-infinity-infinity" accepts the unset
value too).
Includes new unit tests for the C++ and the Lua stringx.parse_range functions.
The next commit adds more WML tests, but is kept separate to credit the author.
This started as a change to move common filter functions from unit.cpp to
somewhere that they could be reused for other config-based filters. In the
process a missing feature was found and added, the move is still included in a
single Git commit because the move was required in order to make these
functions accessible to the Boost unit tests.
Two CodeBlocks project files additionally get src/utils/any.hpp added,
which was in one of them but missing from the other two. I noticed because
these are alphabetically at the start of the src/utils file list.
Thanks to @CelticMinstrel for the review comments and Xcode project updates.
For non-Windows platforms this adds:
* a new check for whether the logs directory exists and is writable by attempting to write a single whitespace to a dummy.log file.
* a popup shown immediately after the GUI system is initialized letting the player know if there was an issue creating the log file.
For Windows, this changes:
* instead of writing to the OS temp directory and then attempting to move that file to the logs directory, this uses the same check that was described above for non-Windows platforms.
* the alert shown when writing the dummy log file fails is now a Wesnoth alert message rather than the Windows-specific MessageBox.
* a failure to create a log file does not immediately exit wesnoth anymore.
Additionally, this makes it so that for the default state (logging to file), all platforms follow the same code path by calling `lg::set_log_to_file()`. `log_windows` now contains only the Windows-specific logic needed for handling the creation/redirection of output to a console.
Remove filter.hpp, which wasn't included by any file, and relied on
pane.hpp indirectly via one of the lines removed in this commit. The sorting
functionality seems to have moved into pane.cpp when matrix.hpp was added.
Note: there are two other unrelated `filter.hpp` files.
Header pane.hpp is only used by matrix.hpp, pane.cpp, and window_builder.cpp;
the class is also used via a forward-declaration in window.hpp, which friends
it, allowing a call to window::layout_linked_widgets. The class is also made
accessible via REGISTER_WIDGET.
Part of #6540.
This file seemed to be some sort of reimplementation of <cassert> except
with some "feature" of trying to force the debugger to hit a breakpoint.
However, any decent debugger already hits a breakpoint with a standard
assert(), and this file really only served to make it harder to see the
actual error when using a Windows console.
Some instances of these macros were replaced with assert(), others with
VALIDATE() which instead throws an exception (and possibly puts up a
dialog, if the exception is caught before main()).
A few other related changes that got mixed in:
- Several error conditions now have a better error message (or indeed
any error message at all)
- Removed an unnecessary use of std::distance on a Boost iterator range.
- Removed a large chunk of code which did nothing but construct a widget
builder and then crash; the code was unreachable since an earlier loop
did the same thing (without crashing), and the comment seems to suggest
that it was a (seemingly no longer necessary) workaround for some buggy
compilers / linkers.
- noreturn added to the list of compatibilty C++11 features in global.hpp
(Of supported compilers, only VC12 lacks the new [[attribute]] syntax.)
- Fix detection of GCC in global.hpp
# Conflicts:
# src/gui/widgets/settings.cpp
This commit adds a dedicated recall list manager class.
The purpose of this is to
- Simplify the code that interacts with the recall list. Prior to
the commit most such code was based on iteration with explicit
iterators, and called global helper functions implemented in
unit.cpp to wrap the code that finds a unit in a vector. It turns
out that interacting with the recall list was the *only* use of
that code, so we make it a member function of the recall list
manager and take it out of unit.cpp.
Most of the code that touches the recall list was previously
7 or 8 lines with a for loop, now it tends to be 1 or 2 lines,
although further refactor may be possible.
- Improve encapsulation. This makes it possible to track how
other classes are interacting with the recall list, and may
make it easier to debug recall list problems by adding debugging
output to the class.
This is a strict refactor, all we do is move the functions and
variables used just for animations to "unit_animation_component",
and include the necessary headers appropriate.
With a bit more work we can probably remove the graphics related
headers from unit.hpp
drawable unit inherits from unit, and implements the draw function,
used only by the display. when the display wants to use the function,
it casts a unit pointer to a drawable_unit, and draws it. this
improves encapsulation.
This use of handle-body idiom saves *alot* of includes, since a
huge number of objects include unit indirectly, and make no use
of the ai formula features.
Currently, the editor does not generate game_board objects, and
leaves the pointer resources::gameboard null. This commit makes
map_location, reports, and tod_manager, three things used in
editor mode, use the display_context pointer instead of the
game_board pointer. We also move a function to display_context,
which finds a const unit * to a visible unit at a hex.
