This changes the component containers away from using a "MAGIC" index in the
placeholder dynamic item tree node it creates. These are hard to
integrate across sub-components.
Use index numbers right after the index numbers used by repeaters and
"extend" the repeater offset by the number of component containers in
the sub-component. This way we can piggy-back on the forwarding of
repeaters.
This has one annoying side-effect: We do have indices in our item tree
that are out of range for a repeater. But I think that is acceptable
considering that we never materialize that array anyway.
When a component declares an init callback as well as the element that
instantiates it, the init callback of the container would not
get invoked if the container was inlined:
```
component InlinedContainer {
init => { ... } // not invoked
@children // force inlining
}
component UseSite {
InlinedContainer {
init => { ... }
}
}
```
That's because the inlining happens very early, before the init
callbacks are collected into the init code. And during inlining that
would be treated like a property binding and the "binding" at the
element site overrides the one at the component site.
One natural approach would be to move the init code collection to an
earlier place before inlining, but that isn't possible because the
boundaries of the compiler components (Rc<Component>) aren't set
up yet (repeated component extraction phase happens much later).
An alternative would be to re-introduce the init callback code in
ElementRc and place it in there at *::from_node() time.
This patch chooses to solve this at the inlining time: When we're in the
first phase of the inlining (the optional one), do what
with the init binding what collect_init_code would do later: Move it
straight into the init_code of the component we're inlining into.
Fixes#4317
A None value means the file on disk is the golden version.
We have an editor, the LSP and the preview that all need to at least
notice when they have newer data then their peers. So IMHO it makes
sense to have an optional document version around.
The language server protocol makes use of a version number already. This
patch moves that code into the compiler so that it is stored with the
actual data getting versioned.
We were using the has_value of the previous expression of a sequence of
expression, instead of using the last expression type to know if there
is a value.
Fixes#4070
the ensure_window and popupwindow passes were looking up the "Window"
builtin in the global register instead of in the builtin register,
causing the presence of an user-defined "Window" to cause panic.
The "Clip" and "BoxShadow" calls are not affected because they were
looking up in the builtin reguister, but using the appropriate function
is more future-proof
Fix#3916
Regression noticed in this line:
3f97d98bff/ui/tabs/downloads.slint (L77)
The following used to work:
```slint
import { Button, VerticalBox } from "std-widgets.slint";
export component Demo {
in property <[int]> mods;
VerticalBox {
alignment: start;
for xxx in true ? mods : [] : HorizontalLayout { alignment: center; Button { text: "OK!"; } }
}
}
```
But we fixed array conversion and this caused a regression with empty
array
If a branch that always return has a "void value" and the side that
doesn't return has a value, we need to synthetize a default value
so the struct is complete, even if that value is not used.
If you have a window like so:
```
component W inherits Window {
width: 200px; // or some other bindings
}
```
Before this patch, it will be converted by the compiler to something like
```
component W inherits Window {
width: 200px; // or some other bindings
min-width: width; // (not actual property, but part of the layout_info)
max-width: width;
}
```
When the window is on the screen, the platform backend will set the max
with and min width on the window manager window to the value from the
layout info.
But slint will also set the width and the height of the WindowItem to
the actual value. This will break the binding for width if any, and
will also cause the min and max with do be updated, which is wrong.
We haven't had much problem with that before, but with the
ComponentContainer, this becomes a problem as we want to set the width
and height of the inner from the outer by adding a two way binding,
which cause a binding loop at runtime.
The behavior change is that if you have a fixed window size and use that
on a MCU or platform that has a different size, the window will be
cropped or padded but will no longer be resized
commit 975abf3c42 introduced a regression.
Two problem:
- we were taking the geometry from the parent instead of the element
that need the shadow
- Element::make_rc override the geometry with its own properties
Unfortunately annot be tested as this only visual, and the software
renderer don't support shadow yet
Fixes#3743
Parents surch as Opacity, Clip, and co, used to steal the x and y
property of their children, making the property not what they ought to
be.
Now that we refactored recently the code so that geometry need not to be
always linked to a property of the same name, we can dissociate the x
and y property of these generated elements and their content so that the
actual "x" property of the former elementstay some value, despite its
relative item property is now 0.
Had to change a bit of code that was still assuming a literal "height"
or "width" or "y" or "x" property that no longer worked when the
geometry is dissociated from its property
Fix#1072
* Extend the cspell word list
* Remove those extensions from individual source files
* white-list licenses and such as we should not meddle with those
* Fix spelling
This is used in slintpad to map relative image URLs to their real
download locations.
This has the side-effect of removing the service worker.
Fixes: #2905
Resolve an image path to soemthing relative to the syntax node that
pulls it in if the path can not get resolved.
This typically happens in WASM as file existence is checked during image
resolution, which is not possible there.
We see that a lot in the fluent style. For example:
```
font-size: Typography.body.font-size;
```
Where Typography.body is a contant expression define as
```
out property <TextStyle> body: {
font-size: 14 * 0.0769rem,
font-weight: regular-font-weight
};
```
But because this first converts from an annonymous tuple struct to a
named struct, the const propagation used to be confused. Now with this
patch it is properly simplified
Before this change
cargo run -p slint-compiler -- examples/printerdemo_mcu/ui/printerdemo.slint -f rust | rustfmt | wc
38643 84506 1925846
cargo run -p slint-compiler -- examples/gallery/gallery.slint -f rust | rustfmt | wc
103210 224427 5291034
After this change
cargo run -p slint-compiler -- examples/printerdemo_mcu/ui/printerdemo.slint -f rust | rustfmt | wc
38629 84473 1924995
cargo run -p slint-compiler -- examples/gallery/gallery.slint -f rust | rustfmt | wc
102628 222423 5261760
Layout code generates a lot of code and it may be beneficial not to
generate constraints if there is no constraints in that direction
Before the change:
cargo run -p slint-compiler -- examples/printerdemo_mcu/ui/printerdemo.slint -f rust | rustfmt | wc
40014 86643 2010535
cargo run -p slint-compiler -- examples/gallery/gallery.slint -f rust | rustfmt | wc
105715 229009 5434115
After this change:
cargo run -p slint-compiler -- examples/printerdemo_mcu/ui/printerdemo.slint -f rust | rustfmt | wc
38873 83654 1925830
cargo run -p slint-compiler -- examples/gallery/gallery.slint -f rust | rustfmt | wc
103817 224874 5316553
No measurable changes in compilation time.
Add some code to do platform-independent path processing.
This is necessary aas WASM does e.g. not have any absolute paths and
such and the compiler tended to produce wrong results in that case.
Side-effect: We no longer need to depend on `dunce`
Since they no longer have a builtin width/height property, the test
that checked the type was wrong. But since we can't override the width
or height property with another type, this should not be relevant
This doesn't work yet as we need to do more "patching" of anything that
uses the x and y properties
This reverts commit 2d6fec78f9ff01c8b4904685fae0ce587a3c8e9a and
036ddfe23aa5f5b63778b8056d58c30c08f942fe.
The WindowItem did not have a x or y before, so these property
were unused for it's geometry(), but now it is used in the new
item_geometry on the ComponentVTable.
So make sure we don't initialize them
So it doesn't appear in the LLR and the C++ codegen can be simplified.
In particular, this removes the need to throw/catch exception to handle return
across generated lambdas
In the case of bug #3318, the implicit alias to the window's height or
width was removed but the propery was not marked as externaly modified,
causing later pass to optimize and inline things that shouldn't
Fixes#3318
