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.
A really clean build still brough up the issue that the C++ code was failing to build.
Instead, guard those places with #cfg just in the style crate and provide
"empty" items otherwise. That also simplifies the usage site again.
This time tested with git clean -fdx :-)
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.
This allows specifying additional component locations. It works for
simple structs, but not yet for more complex types due to a bug yet to
be fixed :-)
Move run_passes into the library compilation function. That way the
FileDiagnostics are created by the parser, can be passed on to the library
compilation function and after that we don't need them anymore and can
replace them with future BuildDiagnostics for example.
Don't require the callers to hold on to the source code string until an
eventual diagnostics code path is hit. Instead it turns out it's
simpler to let the parser consume the source code as string, where
internally after tokenizing it can be moved into the diagnostics and
from there into the code map if needed.
There are a few places where we now clone the source code, but that's
only in cases where we also extract stuff separately (test code) or the
syntax updater.
For a .60 files the locally defined components are now stored in a separate
per-document TypeRegistry instance that falls back to the global registry
for lookups.
