This is only exposed when internal types are exposed (such as in the lsp).
The plan is to make this public under a new name/global after the release.
Co-authored-by: Olivier Goffart <olivier.goffart@slint.dev>
By default it's enabled, of course. This property is not only added to
MenuItem, but Menu as well - since they can be nested. It's also
possible to select a disabled item, but it's hard to modify that since
it's logic is written in Slint. You should be prevented from activating
it with a tap or key press at least.
See #7791
Although std-widgets provides many properties that adapt to the current theme users who would like to go beyond these properties and do theme dependent changes are limited. One option would be to add even more properties to the Palette, however this would potentially bloat the object, it's not obvious what properties users care about and this approach doesn't scale. In many cases developers could simply create their own properties if they knew what the current runtime theme was.
This simple change allows an app to know what the current theme is and present theme appropriate UI's.
`ContextMenu` -> `ContextMenuArea`
`ContextMenu` must have a `Menu` child.
`MenuItem` can no longer be put dirrectly in `MenuBar` and can no longer
have children
`Menu` is used now for sub menus
Apply similar logic as to LineEdit and TextEdit, so that when folks build their own text input widgets, they're accessible by default. Also fixed the docs while at it to mention default applications.
Amends #7669
With usual copy/paste entries
We need to make sure that showing the popup window don't clear the
selection in the TextInput which happens if the TextInput gets a
FocusOut event.
Having the width depending on the height is asking for trouble because
usually it is the height that depends on the width, so if the SpinBox is
getting in a complex layout, it causes a binding loop.
Workaround the problem by using the computed height.
This should fix the gallery build with the material style
(which is currently making the nightly build fail)
* ComboBox: Don't change on scroll uless we have focus
This is what native Windows combobox does.
Otherwise this causes problem when combobox are in scrollable
Fixes#5929
* ComboBox: Don't scroll at all with the wheel on Mac.
This is also Qt's behavior
https://doc.qt.io/qt-6/qstyle.html#:~:text=SH_ComboBox_AllowWheelScrolling
* Set `accessible-action-default` on `ListView` items
* Set `accessible-role` on `ListItem` for Qt style
* Set `accessible-label` on `ListItem` for Qt style
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>
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
- 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)
