This allows querying things such as the user's home dir, drive letters
(Windows-only), and game paths such as the data dir, preferences, user
data, and binaries. The results are presented in a format that's
suitable for UI use, with translatable labels used wherever applicable.
At some point there'll be support for listing user-defined bookmarks as
well.
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 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.
This does a few things:
* Refactored adjust_surface_alpha to use SDL_SetSurfaceAlphaMod
* Made all uses of the legacy SDL_SetAlpha use adjust_surface_alpha
* Made adjust_surface_alpha now take a non-const reference and perform the operation on the surface directly.
This file seemed to be some sort of reimplementation of <cassert> except
with some "feature" of trying to force the debugger to hit a breakpoint.
However, any decent debugger already hits a breakpoint with a standard
assert(), and this file really only served to make it harder to see the
actual error when using a Windows console.
Some instances of these macros were replaced with assert(), others with
VALIDATE() which instead throws an exception (and possibly puts up a
dialog, if the exception is caught before main()).
A few other related changes that got mixed in:
- Several error conditions now have a better error message (or indeed
any error message at all)
- Removed an unnecessary use of std::distance on a Boost iterator range.
- Removed a large chunk of code which did nothing but construct a widget
builder and then crash; the code was unreachable since an earlier loop
did the same thing (without crashing), and the comment seems to suggest
that it was a (seemingly no longer necessary) workaround for some buggy
compilers / linkers.
- noreturn added to the list of compatibilty C++11 features in global.hpp
(Of supported compilers, only VC12 lacks the new [[attribute]] syntax.)
- Fix detection of GCC in global.hpp
# Conflicts:
# src/gui/widgets/settings.cpp
While they did contain settings that are required for Wesnoth to run
correctly in the Visual Studio debugger, these settings can also be
specified in the main project file (even if only by manually editing
the XML).
Including the *.user files is problematic since it also includes things
that a developer may wish to frequently change, such as command-line
arguments.
Thus, the settings have been moved into the main project file.
