mark libs on which we have only a header dependency
remove "boost thread" from the list since it was determined (in conversation on irc) that we don't need it
the dependency manager cannot handle campaigns, we work around this by forcing the dependency manager to accept any modifications for campaigns.
fixes https://gna.org/bugs/index.php?22334
This is intended to silently fail on Unix-like platforms where no procfs
is available, and indeed that's how it works in the non-BFS
implementation of get_exe_dir(). The caller (currently a single function
in game.cpp/wesnoth.cpp) must be able to deal with this situation
in a graceful fashion.
update_all_button's value is obtained from operator new, which will
throw if the allocation fails, so it can never be NULL in subsequent
statements.
Found by coverity.
Fixes bug #22962, reported on the forums as affecting the Swamplings
add-on from 1.10: <http://r.wesnoth.org/r41129>
This is most likely a regression from 1.8.x, as it doesn't affect 1.8.6
and the reporter on the forums claims it affected 1.10.x.
Direct substitutions do not require the instantiation of a new
preprocessor_streambuf, instead inheriting the current context's
streambuf, along with its textdomain. preprocessor_data() is then
constructed with an overruled textdomain which leads to a no-op as it is
identical to the streambuf's current textdomain.
Nested substitutions _do_ require a new streambuf created by means of
its copy constructor, which leaves the new streambuf's textdomain set to
the default of PACKAGE (defined as "wesnoth"). Then a new
preprocessor_data context is instantiated and instructed to overrule the
initial textdomain with the macro's textdomain. However,
preprocessor_data's base class constructor (`preprocessor`) has already
copied the streambuf's initial textdomain id to its previous textdomain
record, causing it to restore that textdomain on destruction instead of
the correct one.
Thus, when performing slowpath substitutions we need to make sure the
preprocessor_data and preprocessor constructors see the parent context's
streambuf textdomain instead of the wesnoth default. Later, the nested
preprocessor_data will restore the correct textdomain and emit a
trailing <FE>line directive for the parent if necessary.
The alternative of having the preprocessor_streambuf copy constructor
copy the original streambuf's textdomain would also fix this bug, but it
would break the intended behavior for slowpath file inclusions, which
always default to wesnoth. Although most WML containing translatable
strings have a #textdomain directive at the start nowadays (and this is
in fact enforced by wmllint), it's probably a bad idea to change the
current behavior in this case for UMC, at least for the 1.12.x stable
series.
I do not expect regressions from this commit and it certainly won't
cause compatibility issues or behavior changes outside i18n -- at least
for add-ons that are doing things right and not relying on translatable
strings having the wrong value.
DM, DW, DiD, EI, HttT, LoW, Liberty, SoF, THoT, TRoW, TSG, data/core,
and data/multiplayer all present preprocessor output differences before
and after this fix, but they amount to no changes to the parser's
output; unlike SotBE and UtBS, which benefit from the fix:
* data/campaigns/Son_Of_The_Black_Eye/scenarios/07_The_Desert_of_Death.cfg:439
had the {TURNS_RUN_OUT} core macro substitution bound to the
campaign's own textdomain instead of wesnoth for some reason.
* data/campaigns/Under_the_Burning_Suns/scenarios/05_A_Subterranean_Struggle.cfg:1749
onwards (the ENEMY_ATTACK and ALLY_REINFORCEMENTS macros) bound
several strings to the wesnoth textdomain instead of the campaign's
textdomain.
I also tested this commit with my own add-on, After_the_Storm, which
presented similar results as DM et al above. Finally, Swamplings is
properly fixed by this change.
This is to avoid bad_lexical_cast exception. I'm not sure if in
any cases this could actually have thrown but it's better to be
safe.
Conflicts:
src/server/game.cpp
the adjustments just make it use the more standard SDL utils fcns
for making a transparent (neutral) surface, and they avoid floating
point operations when scaling images
we also fix a bug caused by using "sdl_blit" instead of
"blit_surface", which caused the terrain overlay not to show up
Conflicts:
src/editor/action/mouse/mouse_action.cpp
This reverts commit d73a117278.
This is being reverted because there is still yet more bad behavior
in our alpha channel when scaling images, for instance this causes
the terrain overlays to disappear when mousing over terrains with
one of the editor terrain tools.
The reason is that our "scale image" routine is broken and doesn't
weight color contributions by alpha. It's not apporpriate to get
rid of the hacks like alpha thresholding until that has been fixed
and that can't be fixed on 1.12 right now.
Formerly, the option buttons at the bottom of the dialog were laid out
by redoing some math instead of tracking the dialog's menu position,
which is always valid (even when there is no menu!). I'm not entirely
sure why, but the math reprised here became bogus with the introduction
of top buttons in commit 045bda037d (for
the Add-ons Manager dialog), in particular for dialogs *not* using them
(such as the in-game Statistics dialog), even though the menu is still
laid out correctly.
So instead of reinventing the wheel, we really should just take the
menu's position and height as a baseline for the bottom option buttons.
At worst the height is 0, but the position is still within the dialog's
boundaries (but see below for an unsolved corner case).
This commit reverts commit f60ef98e27
(a.k.a. 69521000dc in 1.12) that's part of
PR #263, because it turns out that the solution proposed there is only a
convenient workaround that solves a layout issue for a single dialog
(Statistics, see bug #22379) and introduces a new bug for another
(Add-ons Manager, see bug #22791).
Regardless of the cause for #22791, the approach put forward by this
commit is more consistent with best practice (laying out widgets from
top to bottom each row's geometry depending on the previous row's), so I
have decided to not look too much into it.
It should be noted that the layout of bottom option buttons breaks
entirely for dialogs missing a menu, both before and after the
introduction of top buttons. Currently there is no GUI1 dialog that
attempts to insert option buttons while lacking menu entries, so I'm not
too concerned about this bug (which affects 1.10 too!). Besides, some
day GUI1 is supposed to go the way of the dodo and stop bothering us
with its marvelous inflexibility and arcane logic.
