The set_origin method worked, but not in every circumstance. For example, if the story box were not aligned to the bottom of the
screen in the initial part, it would not be correctly place. If you resized the screen while the box was not at the bottom, it
would return there. This was due to set_origin being purely temporary - ie, the layout engine did not record the new position,
and when invalidate_layout was called, the default (per the dialog WML) position of 'bottom' was restored.
This new method fixes the above issues. It also fixes an issue the old GUI2 screen had where a top-aligned box would also obscure
any available title.
It was causing problems being enabled for all labels (ie, some labels being shrunken when it wasn't desirable),
and it didn't make much sense for all widgets anyway.
This adds a new can_shrink key to widgets that allows the 'no label' codepath of styled_widget::request_reduce_width to be called.
In this case, it allows labels to shrink without forcing window scrollbars.
This gives the pane some extra height by default so that an initially shown unit will few attacks doesn't
cause a scrollbar to be shown for others with more.
Widgets usually leave it up to the dialogs to provide a border. Since this entire widget is wrapped in
a listbox, there's no need to adjust any internal borders.
This way it's no longer necessary for the containing window to define the
groups, eliminating possibility for an easy mistake if a developer wants to
create a new window that contains an add-on list.
The purpose of this change is ability to create more dialogs which present
a list of add-ons, such as a GUI2 version of the "Install Dependencies"
dialog.
This change is still highly incomplete. First of all, I disabled inline
install buttons and ability to sort the add-on list. In addition, a lot of
functionality that belongs in the add-on list widget is still in the GUI2
add-on manager instead. It is also notable that the widget relies on
several linked groups being defined in the window.
I plan to finish the transition to the add-on list widget, and address the
problems in the previous paragraph, in the future. The linked group issue
is going to require a lot of work in particular: I plan to either make
linked groups grid-specific instead of window-specific (like they are now)
or allow widgets to inject linked groups to the containing window. Either
way, I'm going to change the operation of GUI2 fairly deeply.
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.
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.
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.
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.
