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.
Since Doxygen can't seem to just exclude them via command, they are moved
into a private_api namespace and then excluded via Doxygen config:
* *VTable
* make_dyn_node, ItemTreeNode, etc.
* VersionCheck
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.
The compiler complains that intptr_t is not the same type as "long long".
The "long long" originates from "pub struct VisitChildrenResult(i64);"
and I suppose the compiler is right for potential 32-bit architectures. So
let's use int64_t as counter-part to i64.
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.
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.
