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.
