This is redundant now that PNG support is part of SDL_image and
therefore always available to us on supported configurations. BMP files
are horribly expensive to store.
This additionally:
* Makes all copyright notices identical aside from the starting year for Wesnoth-specific source files. Files not included: mariadbpp, lua, spirit po, xbrz, and bcrypt (crypt_blowfish).
* Removes all attribution from the files, since the vast majority of them are outdated or seemingly just outright incorrect. For example, I would guess that Dave is no longer the sole author of the majority of Wesnoth's current code.
When returning std::unique_ptr instead of raw pointers, the return type can't
be a co-variant, which is why the clone() functions are all being changed to
return the base class.
All of the instances of editor_action_ptr were replaced, except those in
commented-out code. Many of these replacements were with the `auto` keyword;
for the others the reason that I didn't use editor_action_ptr was that I find
`std::unique_ptr<editor_action>` quicker to read than remembering if
editor_action_ptr is a unique_ptr, a shared_ptr or a plain raw pointer.
A large amount of commented-out code in mouse_action_item.cpp and
mouse_action_unit.cpp gets removed, but the commented-out code in
action_item.cpp is left for a future refactor. I think the classes in these
files should end up being refactored with the responsibilty for putting items
on the map moving from mouse_action_item.cpp to action_item.cpp, leaving only
the parts specific to the input method in mouse_action_item.cpp. However,
that's for a separate commit (and separate PR).
the game_config_view object offers const
access to the game_config object, furthermore
it allows the game_config config object to be
replaced by a vector of config objects which
is what we will do later.
There are only 3 places where it's actually really needed. Used the game_config_manager
singleton to retrieve a reference in those cases.
(cherry-picked from commit 4eee386664b66e801bd4498e8730c017af03f0aa)
Regression from commit ecc0dca665737bcb411fbd355edd37df8a9038b8.
Scrolling diagonally requires holding two keys. Now when a key press event
is considered a key press only if there hasn't been a key release in
between, the second key press is no longer considered a key press.
As a workaround, simply activate scrolling on key event even if the event
isn't considered a key press.
When the player holds a key down, the OS generates multiple key press and
text input events. We can't assume that every such event is a real key
press; instead, we need to track whether there has been a key up event
since we last sent a key press event.
Fixes#1711.
I also moved hotkey::execute_command() into the hotkey::command_executor
class, and renamed the existing member function of same name to
do_execute_command(). I did that because the command_executor class was
the best place to store the "press event already sent" flag.
Essentially, we had CVideo arguments being passed down this chain:
- game_launcher
- free-standing MP initialization functions
- campaign_controller
- playsingle_controller/playmp_controller
- play_controller
- game_display
- display
And likewise down through
- game_launcher
- editor_controller
- editor_display
- display
With only a minimal number of actual calls along the way. :| There were maybe... two remaining?
This removes the CVideo arguments and class members from both chains (except of course, game_launcher.
That's where the "real" CVideo object lives).
The display class now initializes its CVideo reference from the singleton, which is also used in the
very few other places it's needed. I also replaced a check for a null video ptr in show_tooltip()
with a faked() check (see src/tooltips.cpp). That seems to make more sense, since CVideo is never
null now.
Turns out I mistook @celticminstrel's opinion that we should use include guards over pragma (737916e).
Since all major compilers support `#pragma once`, there's no reason not to use it.
For future mergability reasons, this excludes src/spirit_po and src/xBRZ. It also excludes src/boost-patched.
This reverts commit 42cb55fa24ca79b43d3a5fc7f29841fce77eea34,
which broke generated menus in the editor due to changing the signature
of a method that was overridden from two superclasses.
I realized the the theme menu class doesn't contain the *parsed* data - which should indeed be in a config -
it only contains the *ids* of the menu's contents. Therefor, there's no need to store the list of ids in a config,
since it would only have one entry. A string is therefor sufficient.
To enable the input and output vectors being different types, I cleaned up the output initialization loop in
controller_base::show_menu
This constitutes drop-in replacements for:
* boost::shared_ptr
* boost::scoped_ptr
* boost::weak_ptr
* boost::enable_shared_from_this
* boost::static_pointer_cast
* boost::dynamic_pointer_cast
This excludes boost::intrusive_ptr, except for stray includes. Refactoring that is more complicated.
Track whether each scroll direction is enabled separately.
This avoids odd behavior when holding multiple hotkeys for the same
scroll direction.
For example, holding two hotkeys for right and releasing both will no
longer cause the map to begin scrolling left.
previously it showed the default "do you want to quit the game" message
when leaving the editor. using the red cross in the corner.
This also changes some dublication of the "Do you really want to quit?"
translatable string in the c++ code.
command_executor_default which is used ingame and by the editor now
handles display related stuff. (map screenshots, zoom...)
this also removes a hotkey::basic_handler form titlescreen which didn't
work anyway becasue it didnt pass a hotkey_executor.
File paths are recorded into the game preferences up to a (currently
hardcoded) limit of 6 and opening or saving maps adds or bumps existing
entries to the top. We may allow users to change the MRU limit in
Advanced Preferences in a later commit.
Adds two translatable strings.
In order to fit file paths in the menu without filling up the whole
screen sideways, we use only the file names for now. Because identical
file names could prove to be an actual issue later, I intend to look
into ellipsizing paths correctly in a later step.
(Note that I'm piggybacking on the crummy submenu support we already had
in the themable UI so that this can be safely backported to 1.12. It's
decidedly not optimal usability-wise, but it'll have to do for now.)
Instead of inheriting from hotkey::command_executor,
controller_base now returns a pointer to a command_executor.
With current implementations all controllers return this, but in
some cases it may be simpler to have a separate small class for
this.
