This is technicly a breking change. But this is also a bug and it was only
allowed since 0.3.2, so it is probably fine.
The problem is that any property access to a global was considered as being
local.
Now, change that so that property access to a global object is no longer
local, and other components can't access private property anymore
This reverts commit 000d95670b and commit
d764796e0c to fix arm cross build and
x86-64 linux.
Let's use the core::ffi types when fontconfig-sys switches to it.
Make sure this is the actual builtin type we are looking at and not a
re-defined component
Doesn't work for ListView unfortunately because ListView is not a
builtin type
CC #861
The previous code did not remove two ways binding that were between two
globals. Now we do the remove_aliases pass over the whole document at
once which allos to simplify aliases between globals.
When doing builds that require image embedding (such as for WASM), it's crucial
to also visit the globals (after they've been collected) to catch all image references.
Fixes the bug that caused the TextEdit in the gallery to sometimes be
empty.
Generated default value without any priority means it should not be
taken against a real binding if set
Limit the dependency tree of things like the interpreter or the C++ compiler that
doesn't support it anyway.
It is still enabled inconditionally in slint-build though
The test was only failing in some cases with node because of the
inlining in the interpreter, and it depended in which order the property
were processed (they were in a hash)
A test property was added to also test the interpreter
When having a binding such as
```
foo <=> bar
```
The default value will always be the value of `bar` regardless what's
the value of foo.
This change of behavior is the only one that makes sense bacause if we
are having repeater or if, this will be a problem. eg:
```
property <xxx> bar;
if (some_cndition) : SomeElement {
foo <=> bar;
}
```
Then we can't possibly take the default value of foo for the value of
bar since it depends on the condition. (and it is even worse in case of
repeater)
This is a change of behevior, this is why the tests have changed. The
cse of tests/cases/bindings/* were already covered by a warning since
0.3.0 so that should be fine. But the warning did not trigger for
builtin property such as `visible` (eg, input/visible_mouse test)
Also some internal two way bindings had to be reversed.
cc: #1394
Permit the style metrics to provide a `default-font-size` and bind that
to the `Window` if set. If not provided, then the backend can set a
`default-font-size`. By ensuring that the value is non-zero at run-time,
we can later introduce a rem unit that can act as factor relative to
this non-zero font size.
These are two different concept, and it is confusing to keep them in the
same enum
We want to support component without any base element, and Void is
already used for global component, so do this refactoring before
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
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.
This is the most basic loop and we wouldn't show a signal.
Turn out the comment was wrong and we do not seem to emit the error
twice for two ways binding to itself
Fixes#1407
