Also:
- The newer version of femtovg permits disabling text layouting, so this means less dependencies
- Skia is the only renderer left to support wgpu 26, so unstable-wgpu-26 now implies a dependency to renderer-skia
Closes#9605
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.
This fixes a regression seen with 0910024aeb
where text outlines no longer rendered with Qt and the text color
was wrong in general.
It turns out drawGlyphRun doesn't work when drawing outlines. It
only uses the current QPen color and that's it - so not a built-in
way to draw the outlines separately. There was also another bug
where we weren't setting the correct QPen color, which regressed
any dark themes. (Presumably because no one expected it to fill
text with the QPen!)
We can fix this by only using drawGlyphRun for filling in glyphs.
For drawing the glyph outlines, we can skip the built-in QPainter
functions altogether and use QRawFont's ability to create
QPainterPaths for us. This restores the text to its previous
appearance while keeping the nicer text layouting!
- Replaced the previous `cfg_if` macro usage for detecting Apple platforms with a new `is_apple_platform` function in `lib.rs`, improving code readability
- Updated the `window_event` function in `event_loop.rs` to utilize the new `is_apple_platform` function for determining the `swap_cmd_ctrl` variable.
- Simplified the logic in `wasm_input_helper.rs` for checking if the platform is Apple by using the new function.
- Adjusted the `text_shortcut` method in `input.rs` to leverage the new platform detection, ensuring consistent behavior for keyboard shortcuts across Apple devices.
In a LineEdit with a long text, when dragging the selection
to the point where the anchor scrolls out of view in the other
direection, it used to keep being visible, outside the LineEdit.
This commit fixes that by passing the clip rect to the java code
that positions the selection handles.
* 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
* Start on touch event rotation work
* [autofix.ci] apply automated fixes
* Use ItemTransform instead.
* [autofix.ci] apply automated fixes
* Use casts to deal with integer Coords on some platforms
* Remove rotation checks
* Transform the exit event as well
* Delete check_rotation pass
* Do casts around transform_point to handle i32 Coords
* Remove errors from rotation syntax test
* Basic event rotation test
Working changes
* Fix clicks on rotated objects
* Add RendererSealed::suppports_transformation for runtime checks
* [autofix.ci] apply automated fixes
* Add a few missing line breaks, only transform events if supported by
renderer
* Improve test
* Remove extra whitespace
* Get absolute-position working
* Ensure map_to_window does the coordinate cast thing.
* Manually test mouse-x and mouse-y, test absolute_position()
* Whitespace stuff again
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
The new release rustix 1.1.1 fails to compile on android when it's
feature "process" is activated. This is enabled by the zbus crate
We do not need zbus from i-slint-backend-winit on android
(actually we do not usually use that backend on android, but we just
compile it there on the CI for the internal docs)
Improve detection of explicitly sized canvas elements, by looking for css rules that applie (!= "auto" in computed style) or explicit inline style width/height.
Commit 1c73144b09 (famous resume protocol) change the overal timing and sequence of window creation. As it happens now, when
we set_visibility() is called and we try to preserve a "browser" assigned canvas size,
we do so even for windows where we decided we want to go with the preferred size. This restores the todo/underlay/etc. demos.
With commit bcfa1eaa2e we now end up computing current_size as (10, 10) for the slide puzzle (which has no min-width in Slint),
which differs from (0, 0). But we really shouldn't try to assign a size in the first place.
Set DRM_CLIENT_CAP_UNIVERSAL_PLANES before calling plane_handles() to
ensure all planes (primary, overlay, cursor) are visible for format
detection. This fixes cases where plane enumeration returns empty
results due to missing client capabilities.
Signed-off-by: minicx <minicx@disroot.org>
Instead of failing when no plane formats are detected, fall back to
XRGB8888 which is widely supported. This prevents crashes on systems
where plane enumeration fails while still allowing the display to
function with a common pixel format.
Signed-off-by: minicx <minicx@disroot.org>
When the state of menus are changed, the `muda` representation of menus is completely torn down and rebuilt. On Windows, this can create a slight flicker unless the act of redrawing the window is disabled. With this change, we use `WM_SETREDRAW` to disable redrawing while the menus are being reconstructed.
It isn't clear to me if other platforms have a similar problem.
- Take in account the scale factor (unfortunately we don't have access to the actual window scale factor so just use the Qt one)
- Draw directly in the final SharedPixelBuffer
- Use an intermediate Rectangle to center the image because otherwise we get height for width dependency that breaks layout.
Set up the underlying graphics API with WGPU, render into the queue with
skia, present with WGPU. Opens path to importing wgpu textures, provided
that we synchronize them (i.e. pipeline barriers/transitions if needed).
When the API set_visible() call comes in, but we don't have a winit
window yet, make sure the WinitWindowAdapter is registered for window
creation.
Test: tests/manual/windowattributes -> toggle visibility under wayland
* Add support for the Back key on Android
Successfully tested with this code
```slint
forward-focus: my-key-handler;
my-key-handler := FocusScope {
key-pressed(event) => {
if (event.text == Key.Back) {
root.close();
}
accept
}
}
```
but also without (that was the hard part: letting Android
terminate the activity on Back if it's not accepted by slint,
which no longer happened after returning Some(...) in key_codes.rs)
After commit e04f028c91, the
default-font-size property on WindowItem isn't set anymore by default,
so BuiltinFunction::GetWindowDefaultFontSize, which reads it, would
return zero.
Instead, delegate to a run-time function where we can fall back to the
default from the renderer.
This patch changes rem.slint to use the newer syntax. The main change to
the test case though is to removal of the explicit default-font-size
property setting, so that we fall back to the value provided by the
renderer. This test relies on being run with the testing backend.
Fixes#8961
Enabling the wgpu feature in i-slint-renderer-femtovg implicitly enables
the i-slint-core/unstable-wgpu-26 feature, which means the ImageInner
enum has a WGPUTexture variant. That one in turn must be matched in the
Skia renderer, when looking at the ImageInner variants. Fix this by also
enabling the unstable-wgpu-26 feature in i-slint-backend-winit and thus
i-slint-renderer-skia. This doesn't automatically enable the API though.
Don't pass zero min/max sizes to winit, as from there on it might get
back to us, and we'll try to create zero sized rendering surfaces. But
even if we bailed out then, it would be unusable for the user.
For example, this avoid panics or crashes in the live-preview when
editing window/layout code that ends up with a zero min/max height.
Fixes#8926
