The theme layout padding values are parsed and stored as 16 bit
signed integers. However ThemeLayout::setPadding treated the
values as 8 bit signed integeres.
The padding values parsed from the STX file suited for the screen
resolution are multiplied with the device content scale factor.
The scale factor determines how content is mapped from the logical
coordinate space (measured in points) to the device coordinate
space (measured in pixels).
If the scale factor and the padding value results in a value
greater than 255 it will wrap since the 8 bit type can't hold
bigger values than that.
Running the iOS backend in debug configuration on an iPhone 12
mini, having the content scale factor value 3, and drawing the
launcher in vertical mode where the bottom padding value is 92,
the result became 3 * 92 = 276 which would wrap to 20.
That resulted in incorrect layout where the GameList was too
high and the buttons in the bottom would not fit on the screen.
Change the input type to int16 in ThemeLayout::setPadding to
conform with the padding type used everywhere else.
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.
- 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