Padding properties exists as reserved properties but don't have effect.
But the menu code was using them to store values.
This is now a warning because people got confused by setting padding and
wondering why it has not effect.
This also had some bug in the code were properties were padding was set
on a layout, as well as all the padding-* properties, so the padding was
not taking in account
This adds an icon that is displayed to the left of the title, and is
also shown for Menus are inside of a parent menu.
Closes#7791
ChangeLog: Added icon property to MenuItem and Menu
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
