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>
Consider
```slint
// Some code in the wild actually have made their own menubar before
component MenuBar { /* ... */ }
component Row { /* ... */ }
export component Main inherits Window {
// This should find the declared component and not the builtin component
MenuBar { }
GridLayout {
Row {}
}
}
```
Previously, `MenuBar` and `Row` were first resolved against
`additional_accepted_child_types` and so it would always find the
builtin one.
But this patch changes that to find the builtin one only if it hasn't
been replaced by another component with the name name.
(So we'd use the cusom MenuBar and the custom Row)
Another change is that we also lookup the
additional_accepted_child_types if they are in a @children.
```slint
component MyGrid {
GridLayout { @children }
}
export component Main {
MyGrid {
// This used to be an error but is now accepted
Row { }
}
}
```
Within the cupertino's ScrollView, the Flickable is positioned
with a 2 pixel margin with the `x` and `y` properties
property, so the width and height should also account for that margin.
Fix the test_cpp_elements_listview in test-driver-cpp
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)
It can panic if lazily constructing the window adapter.
Make sure it is actially not lasily constructed, we don't need lazy constructor when not embedding anyway.
Introduce two new properties for string in .slint:
- .is-empty: Checks if a string is empty.
- .character-count: Retrieves the number of grapheme clusters
https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries
These additions enhance functionality and improve convenience when working with string properties.
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
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).
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
