Test for issue #194 which was already fixed.
And also fix a small other issue where the preferred size was not properly
computed in layouts.
Closes#194
A few problem:
- the horizontal and vertical property were swapped
- The implementation of the "preferred_xxx" property was not materialized properly
because the `bindings` were borrowed in the materialize_fake_properties pass
- Since the Window has a stretch factor of 0., the preferred size of the inner layout
was not taken into account when merging the LayoutInfo. I believe taking the
maximum preferred size is the right solution when merging them.
Since we split the horizontal and vertical part, the stretch dependency is a bit overkill
and we can re-implement it ourselves.
This will also allow us to support colspan and rowspan properly
Split the vertical and horizontal pass into different property cache
This will allow to implement "height for with"
This patch does not port the Rust or C++ binding yet
Instead of using a solve_layout function in the component, use property to hold
a layout cache.
This commit only implement the GridLayout and only the interpreter part
Commit 843f52b3c5 erroneously applied the cross-axis
preferred size, which breaks the
images in buttons in the printer demo.
Also use the same value for shrink as for flex-grow, as advised by Olivier :-)
In the nightly it appears that `no_mangle` is now considered "unsafe",
so we need to allow that in the ffi modules. For the layout code this
patch also creates that ffi module with prefixed function names, like in
the other modules and only allows unsafe in there.
Use only specific lyon packages instead of pulling all of them in.
This slightly speeds up compilation as well as for example lyon_tesselation
doesn't need to be compiled anymore.
* Always apply a transformation (less variants)
* Let the path data iterator take ownership of the data. That will
make it possible to return a PathDataIterator from a function in the
future
This patch distributes the constraints evenly to the occupied cells.
That is not entirely correct, but it's an improvement for the appearance
of the todo app.
Unfortunately nesting the boxes to model a grid does't seem to quite
work, so this approach simply creates two boxes for each direction --
similar to the existing algorithm.
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.
When the spacing was zero, the constraints would always be zero due to
accidental multiplication with the accumulated spacing widths/heights.
That was meant to be an addition.
