Most of these were wordier than necessary (e.g. "Save the Map As"
instead of "Save Map As). Also replaced "want" with "wish" in external
prompts at vultraz's suggestion.
This allows the user to use the arrow keys to select fileview entries,
and character keys to enter a name into the textbox below, just like in
the GUI1 version.
Thanks to celticminstrel and vultraz for the tip.
The previous logic reinvents filesystem::directory_name() in a
platform-dependent fashion (it will break if the wesnothd path in
preferences has backslashes on Windows, which is exactly what the GUI2
file dialog delivers), and uses the compile-time install prefix
(non-Windows platforms) or the current working dir (all platforms)
instead of using the game executable's directory, which we can reliably
obtain on Windows or Linux, and automatically fall back to the cwd
otherwise.
Using filesystem::get_exe_dir() as a starting point instead allows for a
much simpler and platform-independent logic (except for the .exe
extension for the binary on Windows, of course).
This switches all existing callsites to using gui2::tfile_dialog, and
fixes a build issue due to editor/controller/editor_controller.cpp
relying on an indirect include from gui/dialogs/editor/custom_tod.hpp
for a full type declaration.
This allows setting a hint in save mode so that the name portion of the
filename will be selected whenever the user selects a file with a
matching extension on the fileview, and so that whenever the textbox is
cleared by code (e.g. when browsing into directories) it is pre-filled
with the extension with the cursor at the start.
With this, the dialog is now feature-complete compared to the GUI1
version.
Unlike the internal (protected) methods, this makes sure to call
update_canvas() when done so that e.g. text_box's highlight rectangle
is properly updated on the canvas with the right variables so that it's
drawn after we're done handling events.
This provides, as far as I can tell, all the filechooser functionality
that is actually in use in Open File mode except for the "type-ahead"
option that is used to set filename extension hints.
There's some newly-introduced border cases courtesy of Boost.Filesystem
that I really feel we shouldn't worry about for now:
* // is handled weirdly thanks to BFS honoring the POSIX provision for
implementation-defined behavior regarding it.
* UNCs on Windows are not supported. Just like in mostly everywhere
else in Wesnoth. Same applies to \\.\, \\?\ and \??\.
* Non-directory path components on Windows are not handled very
gracefully (particularly obvious with volumes mounted as NTFS
junction points, or symbolic links for the Documents folder on
Wine) due to quirks in BFS's path::canonical() method and how it
relies on dereferencing individual path components to resolve dot
entries.
Haven't tested all callers yet, they are still using the original
filechooser entry points for now. I need to remove those and make
everyone use gui2::tfile_dialog directly before this can be merged to
master.
These include an alternate mode of normalize_path() that enforces the
platform's preferred path delimiter (i.e. backslash on Windows) on the
output, and a function to detect whether a path refers to a root
directory.
Unfortunately, the last bit requires introducing a new link-time
dependency on Windows, against a system library. It's guaranteed to be
always there but it seems kind of a waste. The alternative would be to
hand-parse the string but that seems even more of a waste. And no,
Boost.Filesystem can't do this in a straightforward fashion right now.
Attackable enemies are defined as visible (can’t attack it if I can’t
see it) and not petrified.
This is in preparation for making the Micro AIs deal correctly with
hidden and petrified enemies.
This reverts commit 9a569df848f3b7d774ac29c100a4f36c4923b7bd.
This commit somehow causes massive lag when opening the Campaign dialog with a large (several hundred) saves.
Somehow, the save_index was being regenerated every single time a new save was processed, likely due to
the calling of save.summary() in the create_engine initialization loop. It remains to be seen if this is a bug
in the save_index code, which seems possible.
This commit was also likely the cause of bug #25146. While the fix for that might have been simpler (short-circuiting
the campaign type conditional with a savefile corruption check), since this commit has already caused issues, it's
best to revert it and revisit this idea at another time.
He used to have an unintended random trait which got re-randomized when he changed type. Now he simply levels up to a Sea Orc, which works better visually as well.
Commands run:
find . -type f -name "*.hpp" | xargs coan source --replace --no-transients -U"SDL_GPU"
find . -type f -name "*.cpp" | xargs coan source --replace --no-transients -U"SDL_GPU"
This was followed by grepping and a bit of manual editing to remove
defunct TODO items and the empty sdl/gpu.hpp file.
The code conditionals using SDL_gpu in the source tree are unmaintained
and likely broken. From past discussions with vultraz and Aginor, the
plan ahead is to completely drop SDL_gpu and its support code once
there's no risk of conflict with certain WIP branches.
Pretty much all of the code for supporting OpenPandora is gone from the
source tree, and the last two mentions have just been slated for
removal, so it's effectively dead.
