We support directly nested layouts, but we did not support indirect
nesting:
GridLayout {
Rectangle {
l2 := GridLayout { ... }
}
}
This patch fixes that by detecting this scenario and merging the layout
info of the element (Rectangle) and the layout inside (l2). This makes
it much easier to create re-usable components that use layouts
themselves and allows placing them in layouts.
This does not actually merge so much but it is better than nothing.
I was not able to merge the code from the interpreter because of the life time issues
Instead, pass a reference to the root item when mapping the window,
at which point we can downcast to the new Window item. If we have one,
then we'll read its width/height (for initial values) and install
bindings to keep them up-to-date.
This adds horizontal_alignment/vertical_alignment properties, along with
width/height to Text.
This still uses a hard-coded enumeration in the compiler, which is meant
to go away in favor of general enum support.
Map it to 800x600 logical pixels for a better initial look.
This implements respecting the initial values for width/height and tries
to apply them to the window begin created.
The PinnedOptionalProp wrapper is needed because while cbindgen mapped
the previous Option<&...> to a raw pointer, the new Option<Pin<&...>> is
not detected as a pointer.
It doesn't really make sense to have them in the API, the grid layout is
supposed to "own" the surrounding space. That can be an element and then
it should be a (0, 0) and distribute the element's width/height, or in
the future it can be a cell of a grid layout. Then there's an (x/y), but
that's implicit / hidden.
Instead of storing the "within" element that we unconditionally take the
"width" and "height" properties from, let's pass through a property
reference expression to the width/height to use. For now that's still
the layout parent's width/height, but with this it can be replaced in
the future to refer to a "virtual" property that belongs to parent cell.
The Rectangle element has properties for a border outline. If those are
used, then the generated code should use BorderRectangle. But if they are
not used, then we can fall back to just generating a Rectangle.