Highly unreliable and generally useless, see the Doxygen documentation.
Also missing the actual Windows implementation for the moment. Also,
since uname() is highly useless on most platforms, I'll need to think up
a better OS X implementation later down the road.
Registers library versions in a single structure that can be queried
later as many times as necessary (say, from the game UI) instead of
relying on recording this information in different object files in an
inconsistent fashion. Also, it provides a pretty formatter for console
usage (e.g., in --version).
libpng also gets to join in the fun.
This is only recognized by the game client at the moment. The
implementation is a bit hacky but it seems to work. Thanks, SDLmain.
The cwesnoth.cmd Windows batch file passes --wconsole to Wesnoth in the
command line, along with any other arguments passed to it. This is
intended to be *the* use case for --wconsole, since otherwise the fact
that Windows won't allocate a console for us on process initialization
(due to Wesnoth being compiled with the GUI application flag) causes
issues with the Command Prompt shell -- namely, the shell returns
before Wesnoth allocates its console, allowing shell input to happen
concurrently with Wesnoth's output to console.
cwesnoth.cmd should be used in shortcuts and given Wesnoth's install
path as its initial working directory.
Apparently CB can't deal with invalid XML properly. The result was that
every file listed after that point wasn't being compiled or passed to the
linker, resulting in a flood of linker errors.
The pager is held by the play_controller and wraps around the
wmi_container, if there are too many items it adds "More Items"
or "Earlier Items" entries. These entries have special reserved
ids, if they are selected the pager traps them.
Future work might be to allow the page_size_ to be selected in
the preferences, that is currently left as a variable to make
it easy to support this.
The functionality of tracking observers and displaying chat messages
is moved to a manager class, which the gui owns.
The functionality of displaying notifications is similarly moved out
of the game_display and to a private namespace. (Static singleton
pattern seems okay here since there really won't need to be more
than one of these for a single application, it seems.)
This is consistent with the introduction of the UnitPtr class.
fake_units really aren't different from units, the only difference
is their life time / allocation and ownership. Since we are trying
to use reference counting for all units (to make them safe to use
with animations), the fake units need to be managed by a reference
counted pointer also. This is the easiest way to achieve that.
I also remove some odd code the [move_units_fake] handler --
there was explicit code to remove the fake units from the fake
unit manager, but this is redundant as it is the responsibility
of the destructor.
Code Blocks and VC project files are updated, but
Code::Blocks Scons and Xcode are not.
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.
