See https://rust-lang.github.io/rust-clippy/master/index.html#useless_format
```
__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::useless_format
cargo fmt --all
```
`__CARGO_FIX_YOLO=1` is a hack, but it does help a lot with the tedious fixes where the result is fairly clear.
`__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_lifetimes
```
__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_lifetimes
cargo fmt --all
```
`__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
```
This can only be used internally by the style to implement the actual
ContextMenu
Only the declarative `MenuItem` interface is exposed.
* [autofix.ci] apply automated fixes
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
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
Only the interpreter is implemented so far
MacOs won't work yet because we don't disable the default winit menubar
The viewer don't support removing the MenuBar yet
The first inlining pass should inline any element that has children.
Row is going to be optimized out before the second inlining pass.
In that pass, we shouldn't care if there is no children while inlining
in a `@children`
Fixes#7284
To keep compatibility with existing Slint code
Commit 53e79000a4 added a call to
LayoutConstraints::new which is shown to produce error in the crater
run.
* WIP: swrenderer: use fixed point for the pixmap font coordinate
* swrenderer: signed distance field: move the glyph to the middle
* swrenderer: round the advance instead of truncating it in distance field
* swrenderer: actually align the gplyph on the sub-pixel precision
sub-pixel within the source.
* swrenderer: adapt the threshold for signed distance field
sqrt(2) is the distance to the diagonal, seems like this gives sharper fonts
* Fix bug in the elision, and re-upload the screenshort
the screenshot changed because the afvanced is now rounded intead of
truncated
SmolStr has an Arc internally for large strings. This allows
cheap copies of large strings, but we lose that ability
when we convert the SmolStr to a &str and then reconstruct a
SmolStr from that slice.
I was hoping for some larger gains here, considering the impact
of this code change, but it only removes ~50k allocations,
while the impact on the runtime is not noticeable at all.
Still, I believe this is the right thing to do.
Before:
```
allocations: 2338981
Time (mean ± σ): 988.3 ms ± 17.9 ms [User: 690.2 ms, System: 206.4 ms]
Range (min … max): 956.4 ms … 1016.3 ms 10 runs
```
After:
```
allocations: 2287723
Time (mean ± σ): 989.8 ms ± 23.2 ms [User: 699.2 ms, System: 197.6 ms]
Range (min … max): 945.3 ms … 1021.4 ms 10 runs
```
Don't filter type import with the extension. Instead if the import
statement is having braces, always consider it is a slint file, and if
not, consider it as a foreign import
the deduplicate_property_read was bailing out the replacement if one
part of the coinditional branch do assignment. But the other part might
already have partial assignment, so we must continue
Fixes#6616
The "tmpobj" variable was overwriten because the interpreter (contrary
to rust and C++) don't have scopes for the local variables, and local
variable of the same name would conflict.
(I think this could in theory be a problem in C++ and rust although i
haven't reproduced it)
Other uses of StoreLocalVariable also make the number unique with a
counter
Fixes#6721
Instead of cloning the vector on every iteration level, pass the
scope in and out of the visitation function and push/pop the element
there as needed. This way we can operate on a single vector that
gets moved around, which removes a few thousand memory allocations.
The speed impact is not measurable, as the code also triggers rowan
API that is much more allocation happy.
Still, I believe this patch is still merge-worthy as it also reduces
the code duplication a bit and is subjectively better, esp. from a
performance pov.
