Using #component_id::item_tree for it does not work because the
public component id is not the right one, we need the one from
the current item tree which is not known at compile time
(could be several if the component is re-used accross item trees)
Also disable the code that sets the focus to the focued element for anything
but the window component: before, the setup code was only run for the
non-sub component, but now it is run for every sub component, and we
don't want to set the focus to anything that has a forward focus property
Otherwise this uses the trick of
InnnerCompo::item_tree()[self.tree_index] to retrieve the index of the
first children. This eliminates the tree_index_of_first_child member.
There are two test failures left:
One of them because accessing from within repeaters is not implemented
yet.
The second one because the self.tree_index of sub-components is not
calculated quite correctly yet when calling `init()`.
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.
* Move the C++ elements back into private_api (despite being generated), so that struct_name_to_tokens can generate the right name in re_exports
* When generating the llr_Expression::Struct for the path elements, make sure
that all fields are filled out, to avoid an empty value expression in Expression::Struct
in the Rust generator. Since we don't generate tuples but a named struct, we must provide all fields.
This patch takes care of the lowering of events/coordinates arrays as
path data, which originates from a `commands: ...` string of SVG path
commands.
In order to minimize the path specific code in the generator, the
compile_paths now generates a Vec<Expression> for the events and
coordinates.
A `Path` with `MoveTo`/`LineTo`/etc. sub-elements now maps to an Expression::PathData of type
Type::PathData.
The llr lowering creates an Array of Type::PathElement, which is casted to PathData.
This only covers the element case. The compiled path events are still todo.
The indexes stored in `VisitChildrenResult` are unsigned. We have 64
bits to store two values and we need to have one special value as a flag.
So accept any index `< u32::MAX` instead of `< i32::MAX`, which should
allow for more data to be visited;-)
two problems
- For the interpreter, properly handle the case of an alias to a global
- For the rust generator, we can't return a reference to a property held
in a global, so we must 'inline' the get_xx funciton on sub-components
I used a `#[cfg(..)]` instead of a feature flag because then it is enabled
for both the compiler and the lib at the same time, and since it is only a debug stuff
it does not need to be enabled within the project. So one must enable it with
`RUSTFLAGS='--cfg sixtyfps_debug_property'`
