Looking at this more I realized the help_button was a GUI1 dialog component meant to open the Help
dialog. Since all dialogs invoking Help now use GUI2, there's no need for this class anymore. It
also allows a bunch of remaining GUI1 stuff to be cleaned up.
This was a dialog used early in 1.13 during the SP/MP codepath unification to configure certain options.
The modification selection is now built into the Selection dialog, and we decided not to enable other options
like Era selection in SP. The only option we might look to restoring in the future is the "show_connect"
option, but that requires some additional code elsewhere and probably won't be used anyway.
I left the controller passed in an argument for compatibility with the GUI1 dialog, but since that's removed
it makes sense that the dialog handle the creation of the controller, especially since due to an oversight
it made a copy instead of holding a reference.
This also allows storyscreen/interface.*pp to be removed. The START_POSITION was part of the GUI1 implementation
and isn't needed anymore.
This splits the handling of each applicable type into its own helper class to better encapsulate the functionality of each.
It also contains a lot of related cleanup and improvements to the class interface itself.
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.
