The original binding analysis code was considering that all the sub components
were inlined. But when this is not the case, we need to re-analyze each
sub component within their parent.
We also need to take care of reverse aliases
Will cause a .60 compile time binding loop error instead of a
runtime recursion panic in code like issue #772
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.
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
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)
This is a two-stage change, that first centralizes the file I/O code
path for on-disk and builtin:/ files. Secondly the resource embedding
pass now produces diagnostics if a file cannot be located.
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
When trying to reference an instance of a repeated item, for use with
ItemRc or VRef<Item>, the item_index (or id) of the ElementRc is not
directly what we want.
Adjust any element references to the repeater to to the inner instance
after creating them. Also make sure that the enclosing component is
respected in the C++ and Rust generators.
Fixes#422
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.
Throw a proper compilation error.
Note that there may be a bit too many error now when the two
branch of a condition are not the same, but it's better than a panic
When an element gets its width and height from the parent through an implicit 100% binding,
those bindings were missing when an animation was pre-defined.
The provided new-type wrapper offers a function to deal with replacing just
binding expression, instead of the
expression *and* the animation.
Fixes#376
When there is an animaiton but no expression, the binding is
left with an invalid expression.
State was keeping that invalid expression as part of sub expression
this is a regression since commit ba32777cab
When images are loaded by the WASM-built interpreter, we do support
loading them asynchronously via the DOM. In that case we have a property
inside the HTMLImage in the GL backend that becomes dirty once loaded
and triggers re-evaluation of depending properties/layouts. However that
only works as long as uses of the image sizes are in property bindings.
BuiltinFunction::ImageSize however is marked as pure in the compiler, so
this may mean that something like this results in an initial assignment
instead of a binding:
Image {
source: ...
height: source.height * 1px;
}
For Rust, etc. that's fine, but when running in the WASM-built
interpreter the expression needs to remain in a binding. Therefore this
hack tries to narrow down this condition to wasm as target.
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
this implies that we need to make sure the property are initialized in
order so that constant properties that depends on other constant properties
are correctly computed
- 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
