We can't support it with the interpreter, and the compiler running on wasm
is only used for the interpreter.
And this cause compilation issue because some dependencies enable features
that breaks the build
For the MCU port, we need to proccess the image to save them in the binary
in a convenient format.
This patch start this work by trying to anaylyze what format should an image
be using, and saving it as a texture in the binary.
The current graphical backend and the C++ frontend are not yet supported
There was a warning in the C++ generated code in the tests: (in test_cpp_image_geometry)
```
/tmp/.tmpsAMWqZ.cpp:307:85: error: self-comparison always evaluates to true [-Werror,-Wtautological-compare]
this->image_in_layout_fit_ok.set((sixtyfps::cbindgen_private::ImageFit::contain == sixtyfps::cbindgen_private::ImageFit::contain));
^
```
Deoing some simple evaluation prevent this warning at least
This will allow later to be able to operate on the binding despite the
element is borrowed.
Since the Binding itself is in a RefCell, the analysis don't need to
be anymore.
To do this change, a small change in the binding_analysis logic was required
which means that we will now detect binding loop if a binding was causing
two binding loop. (before, only one binding loop was detected)
Consider this code:
```60
Foo := Rectangle {
animate y { /*...*/ }
x: some_binding;
}
Bar := Rectangle {
foo_instance := Foo {
y: some_binding;
animate x { /*...*/ }
}
}
```
We need to make sure that the binding are set with the right animation.
FIXME: the generator should actually handle this case without needing for inlining.
Also, this currently do not work if there is several level of "inheritence"
If there is a Expression::Invalid as a binding (because it has an animation,
for example) we must check that the binding expression in the base is not
constant.
This fixes the rust test `properties_animation_merging` without inlining
(The o4_val was considered constant despite it shouldn't be)
Pass the sub-component as a parameter in enter_component(), as it's needed in the C++
implementation, it's readily available (no need to unwrap again) and Rust will need it, too.
For the following reduced test-case the order in how the dynamic nodes
in the item tree were generated (and dyn indices assigned) differed from
the way the visit_dynamic_children slots were generated:
```
Blah := Rectangle {
for x in 1: Text {
text: "Should be on the right";
}
}
MainWindow := Window {
width: 772px;
height: 504px;
Text {
if (false): TouchArea {
}
}
Blah {
x: 200px;
}
}
```
The item tree node was constructed using build_item_tree, which
basically assigned dyn index 0 to the "repater" for the touch area
and "1" to the one for the repeater inside the sub-component.
Afterwards we traversed the element tree - without descending into the
sub-components - to generate the fields and the dispatch in in the
dynamic visitor. Here a subtle order would result in a mismatch of
indices:
recurse_elem_level_order would end up visiting Text, Blah and then
Text's children, assigning the first dynamic index to Blah.
This is now fixed by merging the two iterations into one.
because we don't want the lowered state property to look like we set a property on it.
Also do the ensure_window before because it need to be done before to be assigned
the default color
Fix the dialog test when not inlining, because it declared all these
xxx-clicked aliases and if we don't propagate their usage, they will be
optimized away
focus() is implemented by calling set_focus() on the window with the absolute item
index as a parameter. The
generate_item_indices pass generates local item indicies,
which need to made absolute.
Sadly there exists a gap in the item tree between the root element of a sub-component
and its children. Therefore each sub-component gets two members passed to the constructor,
the tree_index and tree_index_of_first_child.
The former is to be used when the local index is zero (indicates the root).
The latter is used as base for any children.
In a tree like this:
```
SubCompo := Rectangle { Image {} }
MainCompo := Window {
TouchArea {}
SubCompo {}
Text {
Path {}
}
}
```
The path element would have a local item index of 4, which is wrong. Right before the path
there would be the child(ren) of the sub-component, which
were not accounted for.
This reverts commit b4a2d0a902.
That was not the correct fix, because we need that for
aliases to global callbacks (these can't be actual two way binding
at runtime)
There's a check that verifies that the relative item indices match, between what
the item tree building code in the generator sees and the generate_item_indices pass.
The counting of the relative indices was incorrect with regards to the sub-trees.
Inline sub-components that are used along with children, similar to @children. This way
we don't need to jump through hoops for the correct children
count in the item tree (or their placement/offset).
For the item index generation and the member population for the C++
structs, a level-order variant of `recurse_elem` is sufficient - as also
indicate by the unused item index parameters.
This reverts commit 6e8d463d4bb88720a9682c839c5754959dd57c20.
It's better if the generated code for sub-components implements a
root_item function, instead of blowing up the generated code.
Besides `is_global()` add `is_root_component` to Rc<Component>, so that
we can distinguish between the main component (that should have the full
API, etc.) and supplementary components.
This also avoids the generation of unnecessary members when inlining is
disabled.
Make sure that doc.root_component.used_types.structs has all the
structs, instead of storing them in used_types for each sub-component.
That should also account for the same structures used by different
components.
