`__CARGO_FIX_YOLO=1` is a hack, but it does help a lot with the tedious fixes where the result is fairly clear.
See https://rust-lang.github.io/rust-clippy/master/index.html#/needless_borrow
```
__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::needless_borrow
cargo fmt --all
```
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
```
With the Qt backend, the PopupWindow has its own Window and the focus item is not
always set to that window. Resulting in the focus appearance, but the keyboard event
wouldn't be taken by that item
Fixes#7529
The Text element may be given a size that exceeds its intrinsic size, however we returned the intrinsic size. The broke partial rendering when for example text was aligned within the bigger geometry:
Text {
text: "Ok";
horizontal-alignment: right;
x: 0px;
y: 0px;
width: 100px;
height: 50px;
}
This would return a bounding rect with an origin of (0, 0) and a width of maybe 20px, while the text is being rendered centered in the 100px wide geometry. That in turn meant that if that area with the text was marked as dirty, due to some overlap or for example linuxkms mouse cursor, then the Text element wasn't re-rendered because the bounding rect doesn't intersect with the clip.
One option would be to teach the renderers text_size() about alignment, but it turns out that this is the only place where this is needed. So instead, fix this by using bounding_rect() to cover only the case it was originally introduced for - text exceeding the geometry - and otherwise return the geometry.
Remove the geometry field and merely store the offset/transform. This brings the size down from 40 to 32 bytes on aarch64.
Related, filter_item() now respects the item's bounding rect for the decision whether to draw the item or not.
swap_remove() on a slice needs to operate on len - 1 as index of the
last element, not len.
Reproducible with linuxkms-skia-software and partial rendering enabled,
when moving the mouse cursor outside of the screen.
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
Note that this also make sure that a SharedVector for something that
isn't Sync isn't send. Otherwise we could send a `SharedVector<Cell<i32>>`
between threads, and because it is shared, different thread could modify
the same Cell at the same time, which is unsound.
Since SharedString is a wrapper to ShareVector, this will also add the
Sync impl there
ChangeLog: Fixed Sync and Send bound on SharedVector, SharedString, and Weak
The use of the rotation-* properties creates a hidden Rotate item,
which applyes a rotation to the renderer. This rotation (and translation
by rotation origin) is now also applied when the partial renderer
computes the dirty regions.
Because we set the viewport-width several time to different value during
the layouting of the ListView, it will cause this property to always be
dirty. In particular, this causes permanent restart of the fluent's
scrollbar animation on the size of the handle, causing continous
repaints.
The problem is that the precision of f32 for coordinate wouldn't be
accurate enough with such big viewport to put the elements so that they
are next to eachother.
So put the elements relative to the Flickable instead of relative to the
created moving viewport Rectangle.
Fixes#3700
Note that the ListView still use f32 for the scrollbar value, meaning
that at some point, the wheel stops working as the wheel increment is
smaller than the f32 increment, and scrolling becomes somehow fuzzy.
But this only happens after one more billions pixels now, so one can
have more than 50 millions of elements without much problems
- Add the `entries` property in the ContextMenu
- Make right click on the ContextMenu show the menu
- Use the proper technique to register ContextMenu and MenuBar as
experimental (same as ComponentContainer)
Added image-default-formats with all the format supported by image by
default, and enable that feature by default.
Also put that feature in compat-1-2 for compatibility with user that
have used image 0.24 with enabled features.
Make a new compat-1-10 feature that does not enable default format by
default
ChangeLog: upgraded image crate to 0.25, added a new cargo feature
to enable all image formats. (that feature is enabled by default with
compat-1-2, added compat-1-10 to disable it
Fixes https://github.com/slint-ui/slint/issues/7251
- Fix StandardListView not always getting the focus. Because the
geometry of the FocusScope might be empty but its position is still
in the non-clipped area, but not its center.
- Fix panic when accessing "negative" items if there are hidden
elements in the ListView (#7341)
Fixes#7341
This enables working around bugs in GPU drivers. Especially the GC7000UL
plus its driver on imx8mp has been observed to sometimes horribly degrade in
performance when Skia renders anti-aliased paths (when a function like
`gcoSURF_BlitCPU` shows up at the top of `perf` that's a bad sign).
