This removes the special code for the generated property getters and
ensures type safety in the run-time library for property value setting.
In the Rust generated code we continue to do arithmetic on the scalar
values, that means we immediately extract the scalar, do arithmetic and
rely on the compiler to only allow compatible units.
Danger zone alert: In the interpreter Value::Number can now be converted
to LogicalLength as-is.
- We should not panic if the base type is invalid
- We should try to keep bindings in the Element even if the base type
is invalid
- Fix querying the element at a position in case it is not in the last
component of a file
Group property from the base class they are defined, and for built in
property, group them by category.
Also filter callback and other reserved properties that are not valid
for some elements.
In the documentation and type register, `drop-shadow-blur` is of type `length`.
In `BoxShadow` it is also a `Property<Coord>` and treated as such: the value
is multiplied by the scale factor.
However in `builtins.slint` it was declared as a property of float, which
is incorrect.
This change should not have any visible impact, as the externally visible type
was always length.
Known caveats:
- winit doesn't forward mouse events to the IME, so clicking
with the mouse while composing results in funny effects such
as the pre-edit text following the cursor.
- With FemtoVG there's no text decoration support, thus no underlining
of the preedit area.
This allows setting the RUST_FONTCONFIG_DLOPEN environment variable
to dlopen fontconfig at runtime rather than linking it at build
time. This is helpful for cross compiling to Linux, particularly
because fontconfig has lots of C dependencies. Building a vendored
copy of fontconfig does not work as expected:
https://github.com/slint-ui/slint/issues/88
in the funciton `visit_layout_items_dependencies` we were passing a
NamedReference for a property that could have been in the base
component type of an element, instead of in one of the element within
the current visited component. This would result in wrong computation
done later to find out the "element path" of the property.
We then need to tell the visitor that the named reference is in a sub
component. To do that, we need to visit a PropertyPath instead of just a
NamedReference
Issue 1659 was showing one of the symptoms of this, which was an assert.
But it could also result in wrong analysis (binding loop not detected
when it should or vice versa)
Fixes#1659
For example
Image {
x: 150px;
y: 50px;
rotation-angle: 45deg;
}
will end up rendering as if x and y are zero. This is because during
the injection we "move" x and y to the Rotate
element as bindings, but due to the lack of built-in
x/y properties, dummy properties are materialized
and they are not applied for the regular per-item translation.
Add x/y to the Rotate element and then it works.
and use Rc<dyn PlatformWindow> instead. The alias has to stay with the ffi
functions though and the item vtable definitions,
because we don't have an Rc<> template in C++.
One key difference to the Rust way is what `slint::Window` means. In
Rust that holds the `WindowInner` and `slint::Window` is only exposed as
`&slint::Window`. This is possible because the component owns the
`Rc<dyn PlatformWindow>`, which has a function to return the
`&slint::Window`.
In C++ `slint::Window` is also exposed as `slint::Window&` in the
`window()` getter, but there's no way to get a reference to a C++
wrapper for the Rust `&slint::Window` that the `PlatformWindow` trait
returns. Therefore in C++ `slint::Window` wraps `Rc<dyn
PlatformWindow>`.
We use `const` for the embedded data, which doesn't guarantee a fixed location in memory.
For the image cache when embedding (encoded) image data, we rely on a fixed address.
I observed that in debug builds of the slide puzzle, the embedded data is not always
reported to be at the same address, presumably due to inlining. This makes
the theme switching a bit slower and the cache less efficient.
This patch fixes that by using static instead of const, to guarantee a fixed location in memory.
(This was not observed in release builds, but in theory it could happen there as well?)
Some binding can't be express with the current data structures because
they reference propertis within inner elements within a component.
The fix is a bit involved and the best is to have an error istead of a
panic, for now.
The rotation-angle/rotation-origin-x/y properties are lowered to an
injected Rotate element, that we already had.
This needs further fixes for transforming input events and an
implementation of rotation in Skia.
