Revert part of fd993d0b52
Only keep the change in `evaluate` to fix the leak.
We can't destroy the nodes in mark_dirty as destroying them while
iterating lead to crash
The dependency nodes would be leaked.
(This was particularly bad for the ones from the Flickable's bounds
change tracker since that one has many dependencies, while most change
tracker only have one)
Fixes#8768
Don't drop the ChangeTracker's BindingHolder if it is currently being
evaluated as we still need it later.
There was also a bug in DependencyListHead::clear as it was not properly
updating all the field, and the use of for_each was problematic if nodes
gets delete as we iterate.
Fixes#8741
To be compatible with the 2024 edition, we need to wrap the
`no_mangle` attribute in `unsafe()`.
The parsing for that in cbindgen was only added in the version 0.28,
but we couldn't upgrade cbindgen before because of a regression in
cbindgen 0.27 that prevented us from upgrading.
Now that cbindgen 0.29 is released with a fix, we can prepare for the
2024 edition
When either the viewport gets smaller or the Flickable gets bigger, we
should move the viewport position to keep it within the bounds.
Fixes#7487Fixes#2227
(Also workaround #8147 as the ScrollView will automatically go back in
bounds)
This is a hacky approach, but does help a lot with the tedious fixes.
See https://rust-lang.github.io/rust-clippy/master/index.html#/unnecessary_map_or
```
__CARGO_FIX_YOLO=1 cargo clippy --fix --all-targets --workspace --exclude gstreamer-player --exclude i-slint-backend-linuxkms --exclude uefi-demo --exclude ffmpeg -- -A clippy::all -W clippy::unnecessary_map_or
cargo fmt --all
```
And call `extern crate std` when the feature is enabled.
I've read this is the good practice on how to do it.
So that the std prelude is no longer included automatically.
There is then less difference between std and and no-std build which
should avoid surprises in the CI when we use things from the prelude.
The downside is that there is a bit of churn in the tests
The problem was that the code from #4322 inlined the init code in the
parent Component as at that point, the per-repeater component don't
exist yet.
Fix it by removing the workaround from #4322, but changing the order of
the passes so that the init code are already proccessed before any
inlining. This required to change the order of a bunch of passes.
Fixes#5146
As a drive-by, also add the missing C++ implementation of set_animated_value
for Brush that was discovered by the test. (Code wouldn't compile)
Updated the version from 1.1 to 1.2
Renamed the header to "Slint Royalty-free Desktop, Mobile, and Web Applications License"
Added definition of "Mobile Application" and grant of right
Moved "Limitations" to 3rd section and "License Conditions - Attributions" to 2nd section
Added flexibility to choose between showing "MadeWithSlint" as a dialog/splash screen or on a public webpage
Moved the para on copyright notices to section under "Limitations"
The energy monitor declares a transition on an animated int property,
for which Property<int>::set_animated_binding_for_transition is called,
which in turn calls slint_property_set_animated_binding_helper. The
latter is overloaded for various property types, such as float, Color,
or Brush, and then calls specialized functions from ffi, such as
slint_property_set_animated_binding_(int|float|etc.).
slint_property_set_animated_binding_int uses i32 in Rust, which cbindgen
maps to int32_t, so the
slint_property_set_animated_binding_helper overload also uses int32_t.
Unfortunately, with esp-idf, int32_t is a distinct type from int, and
the overload resolution fails.
As remedy, this change uses c_int instead of i32 in the Rust ffi, which
maps to int.
This seems easier than changing Property<int> to Property<int32_t> :-)
The added functions enable mixing colors and manipulating the opacity
of colors and brushes.
They enable the behavior of some of the available functions from SASS and are
added for future use for adding the Adwaita style (future PR).
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.
