Without an explicit size the layout system does not have enough
constraints to produce nice looking dialogs. Up until now the workaround
was to set explicit an size for some of the widget. This worked well
enough except when resizing down the window up until the widget size
constraints could no longer be enforced. At that point, produced layouts
looked too squished.
Previously it was only possible to specify whether items where aligned
to the start or centered in the cross direction of the layouts. It is
now additionally possible to align the items to the far end of the cross
direction or to resize them to match the size of the layout.
Terminology and behavior are loosely based on CSS's flexbox containers.
Prior to this change, a GUI layout was only affected by the screen size.
Now, a layout can additionally be influenced by the GUI dialog and widgets
that uses it. This capability is leveraged to implement the following
features:
* Layout elements that are not bound to a GUI widget do not take space.
This means that dialogs where the widgets shown depend on for example
a feature being enabled at configure time no longer have blank spaces.
* Widgets can define a minimal required size for their contents not to be
cut. For now this is only used for buttons so their width is always
sufficient for their caption not to be cut. This mechanism could be
applied to other widget types in the future.
DropdownButtonWidget is a button split in two parts vertically. Clicking
the left part triggers a default action. Clicking the right part shows a
list of other actions the user can choose from.
Using this widget on the launcher lets 'Mass add' be a secondary action
of the 'Add' button, removing the necessity of pressing the shift key to
access the feature.
This removes the usage of memset to clear complex structures and replaces
them with constructor methods for the structures which will be executed
when these are instantiated.
All uses of the old target scale API actually wanted to disallow scaling of
the mouse cursor. This commit adapts our API to this and thus simplifies
backend implementations.
Some backends, most notable the Wii and Android, did some implementation of
the cursor target scale, which I didn't adapt yet. I added a TODO for the
porters there.
Instead of running into assert()s due to dumb parser decisions, use
'less than' and 'greater than' width/height conditions on the
'resolution' tags.
Seems better than listing >9000 different android resolutions.
Almost all places where we used XMLParser::parseIntegerKey were using
it like this:
XMLParser::parseIntegerKey(str.c_str(), ...)
Since this makes the code harder to read, I overloaded the method to
also accept Commmon::String directly.
Also removed all .c_str() invocations where necessary.
svn-id: r53479
FR #2821513: "GUI: add tooltips".
Added tooltips for Add Game button, clear field buttons and couple
other.
Current problem: Only first call correctly restores text. I could
not find where restore information gets lost.
svn-id: r49774
- Split out label from PopUp widget
- Aligned every widget on all layouts so GUI becomes to look nice again
- Moved textHAlign to layout properties
svn-id: r41266
