This allows enabling Pango markup in gui2::show_message() and
gui2::show_error_message(), as well as the gui2::tmessage dialog they
depend upon. This was a TODO item mentioned in the implementation of
gui2::show_message(). The default continues to be to not enable markup.
Anonymissimus pointed out that std::vector::data() isn't supported
by all STL implementations (it's only required by C++11). Vectors are
supposed to be stored in contiguous memory, so we can use a pointer
to the first item instead to avoid a superfluous copy.
The new [variation] attribute variation_id is now used to identify the
subtype of the variation. This was done by the variation_name until now.
variation_name is now used to display a translated string to the user.
During creation of the unit tree a new attribute base_ids is stored to
hold a list of the [base_unit]s.
The button to invoke this dialog is currently in Preferences -> General.
This will change as soon as I think of a better place/someone else
suggests a better place for the button.
The goal is to allow users to quickly inspect the various paths used by
the game to locate resources and configuration, for debugging or content
creation purposes. The dialog provides options to copy directory paths
to the system clipboard and browse them using the platform's file
manager software, when available.
This supports X11 platforms, Windows, and OS X. The code was
developed and tested on Debian GNU/Linux, Windows XP, and Windows 7.
The X11 and OS X versions of the function are identical and use an
exec/fork/wait pipeline with the only platform-dependant variable
being the external launcher binary (xdg-open on X11, open on OS X). I
opted for this somewhat ugly approach instead of system() because of
the many dangers resulting from allowing the system shell to
reinterpret the command line at whim.
The Win32 version uses ShellExecute() to launch the default
application associated with the Folder object type, in case Windows
Explorer is not the default handler for whatever reason.
The OS X code path was preliminary tested by mattsc and that's really
all I know about it. More testing on that platform would be very,
*very* welcome, although it is expected to behave pretty much the
same as Linux/X11
