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"
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).
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.
Revert part of the previous commit that tries to do all the pass without inlining
Fixup the few first passes so they work without inlining, but still do a full
inlining for most passes
The goal is to make it work pass by pass until we can have everything without
requiring full inlining
Don't put them in a fake expression.
This simplifies a bit the expression handling, and will make
possible to fix analysis that needs a vew into the aliases
We should not increase the priority when merging two way binding, only when
inlining.
This fixes the iot-dashboard's devices widget which were sometimes not
transparent as they should have been.
This was not deterministic because the order in which the two way binding are
merged is not deterministic because of hash table, and sometimes one binding
ended up having a higher priority as it should have had.
- Mark builtin properties that are modified by the native code as output
- Record wether the property is set by code in the .60
- Add a field that will tell us if a property binding is constant
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
Instead of determining the focus item through item tree traversal and
pointer comparison and storing the intermediate indices in the
components in the tree, remember the focus item by a pair of
VWeak<ComponentVTable, Dyn> and item_index: usize.
This speeds up determining the focus item as well as delivering events,
which can now be done directly after retrieving an ItemRef with
get_item_ref.
This also fixes the duplicate line edit focus in the 7gui cells
test case.
Typically `some_length_prop: 40%` produces an error, but if there's a
matching property in the parent, then it will be allowed and interpreted
as relative value and creates a dynamically updated binding.
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.
Sometimes re-usable components need to act as containers that allow the
user to place other items inside. The component needs to be able to
control the placement of these user-provided elements. That is what the
new
$children
expression inside elements does.