This is supposed to be emitted whenever the user performs an
intentional interaction, which works whenever you scroll the Slint
Flickable with the scrollwheel. Dragging the scrollbar on the Qt
style didn't do anything, since that was never hooked up to this
callback.
I only implemented this in the Qt style, because that's the only
one that uses the NativeScrollView element.
See #9574.
* Add scale method to backends
* Rename Rotate to Transform
* Add scaling to Transform
* Fix tests
* Insert Transform if any of scale-x, scale-y or rotation-angle are set
* Add scaling to child_transform and handle events as a result
* Cargo fmt
* Femtovg clipping
* Fix femotovg clipping
* Add newline to actual_render.scale
* Cargo fmt tools/lsp changes
* Modify docs
* Change type to a float instead of percent and fix defaults
* Add note about software renderer
* Add basic event scaling test
It's nice that the default icon size comes from the style, but sometimes
the user wants a big button with a big icon.
Tested in all 5 styles, with PNG and SVG, with and without icon-size
set.
ChangeLog: Added `icon-size` property to Button
As discussed in API review, we thought that as we don't have bitflag,
it makes more sense to have two boolean properties.
Also change the behavior as the focus out event should always be
forwarded regardless of the policy.
... and call that during key event delivery.
Add `capture_key_pressed` and `capture_key_released` callbacks
to `FocusScope` to expose this functionality.
Add a simple test to make sure Interception of key events works as
expected.
Related to: #102, #6390
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 exposes FocusReason to .slint, and adds it as an argument to focus-event-changed callback on FocusScope to close#8387. It also adds two new callbacks, focus-gained and focus-lost, which are identical to focus-event-changed but are only invoked on focus gain or loss respectively.
In addition to this, it removes the FocusEventReason::AccessKit variant, replacing it with the mouse variant to hopefully make AccessKit more compatible with any Slint code that will use FocusEventReason.
Finally, I added two tests based on focus_change_event.slint, one for testing the FocusEventReason argument and another for testing the new callbacks.
close#8387
ChangeLog: Added `focus-gained` and `focus-lost` callback to FocusScope. Pass an `FocusReason` enum to the FocusScope callbacks
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
So that we can pass the focus into the container when it first
shows.
I thought this would be super complex to do property! What a
nice surprise:-)
Fixes: #4055
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.
This does some refactoring to allow builtin item functions to return a
value:
- builtin member functions are no longer BuiltinFunction, but they are
just normal NamedReference
- Move special case for them in the LLR/eval
`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
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>
- 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)
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).
Make it possible to programatically to switch to full-screen mode
via a new property in the Windows item.
The SLINT_FULLSCREEN environment variable will default set this
property to true. However settings this property in the slint code
will override the SLINT_FULLSCREEN.
Fixes#6665
- Rename `accessible-selectable` and `accessible-selected` to `accessible-item-{selectable,selected}`.
Because the property is for items in list rather than eg Text
- Rename `accessible-position-in-set` to `accessible-item-index`.
- Rename `accessible-size-of-set` to `accessible-item-count` and move
the property to the container element rather than the item itself
