This causes a window scrollbar to appear on 600h (or > min tree height + height of rest of widget) resolutions.
I'll need to deal with some minimum size-setting on a dialog basis.
Both are slightly wider than before. In the latter case, 750 would have matched the old automatic width, but
for some reason, the window's scrollbars were showing. Need to investigate further.
There's an issue with textboxes across separate window instances (e.g.
when firing up the New Folder dialog in the file dialog) each getting a
blinking cursor simultaneously displayed on the screen due to timer
events persisting even when a GUI2 window isn't running. This may cause
repaint issues since the whole textbox may need to be redrawn each time
the timer fires, so it's best to disable it until I figure out a better
way to implement a unique global blinking cursor.
Users can add and remove bookmarks from the end of the bookmarks list.
These correspond to the currently viewed directory and have its name as
their label. It's not possible to remove hardcoded bookmarks. A bookmark
may only be removed after selecting it.
In order to ensure that users will be able to remove their own bookmarks
if they match predefined paths, the bookmarks bar now matches items from
bottom to top instead of the other way around.
The path label above the fileview now stands on its own without the
"Location:" label since it's self-explanatory for anyone who's managed
to get this far and install Wesnoth. The Delete and New Folder buttons
have had their order reversed so that destructive actions are on the
side opposite to the dialog's control buttons (OK/Cancel), the "Places"
heading no longer has a colon.
The bookmarks bar holds predefined bookmarks (as in the stuff
src/desktop/paths.hpp exposes) and allows users to easily browse to them
in a single click. It will eventually be possible for the user to add or
remove custom bookmarks as well.
I might add a method to disable specific irrelevant bookmarks later, not
sure (e.g. nobody cares about the preferences dir when trying to find
wesnothd).
This is used by all widgets that inherit from the textbox abstract
class, ttext_. The cursor is updated every 750 ms by toggling the
cursor alpha every time. When the cursor position is set by a method
(e.g. in reaction to a keyboard event), the cursor is reset to full
alpha, and the blink timer restarted.
The color attribute specifically doesn't support formulas. Adding
support for formulas to it would present us with the issue that commas
are already part of the formula language, so we'd need to update all
existing instances accordingly. So, instead, there's this short hack
used for a very particular piece of functionality coming in the next
commit.
For some reason, I swapped these grow factors in the past since the chatbox was growing... not sure why.
It works fine like this, and plus, the chatbox is now equal in height those in Staging and Join.
This makes it so the "selected" segment of the groove (towards the
slider origin) is drawn with a brighter color than the "empty" segment
(opposite from the origin). Since this obviously wouldn't work with
RGB #FFFFFF, and the color is too distracting anyway (it was pretty much
the only widget using the general *text* color), we now use the standard
UI border colors to match buttons, checkboxes and so on. This should
hopefully help with harmonizing Wesnoth's UI color scheme across the
board.
For this purpose we also introduce a macro for a darker/shaded disabled
text color, used for the unselected segment of disabled sliders.
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.
