The function takes a reference to the `PathLayoutData` struct, which in
turn had a reference to the path data. The old rust generator had
special knowledge of calling solve_path_layout, so it knew to take a
reference of the path data.
In the llr there's no expression to take a reference. However since
PathData is cheap to move/copy (just holds SharedVector), we can pass it
by value (move) in the PathLayoutData.
This also means a copy in C++, which I *think* is safe, because the
constructor and destructor will be called on the C++ side, and the Rust
side still just operates on references or would try to move out a field
from the struct.
This can be reproduced by deleting the last item of the printer queue in the
printer demo.
It is a regression showing up because we now emit the MouseExit event after
the mouse grab as released.
The problem is that we upgrade the weak item, and call geometry() on it.
Calling geometry will re-evaluate the layout cache which will re-evaluate
the model which will result in the component being removed and the cache
entry having less item than expected.
It is ok to simply return 0. for these layout location since the item will
disapear anyway.
* Change SharedVector::as_mut_slice() to SharedVector::make_mut_slice()
* SharedPixelBuffer::as_mut_slice and SharedPixelBuffer::make_mut_slice()
* SharedPixelBuffer::as_bytes_mut() to SharedPixelBuffer::make_mut_bytes()
This is consistent with Rc::make_mut() and is supposed to emphasize
that, unlike the usual as_* operations, it is not a free operation but
may involve work (detaching the data by cloning it).
Amends commit 7384ebdc32
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.