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
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
- Use a version of FemtoVG that uses WGPU 25
- Rename the unstable-wgpu-24 feature and wgpu_24 module
- Fetch bevy from a revision on master branch that switches to WGPU 25
- Move the bevy example out of the common workspace: That way users of the repo don't get bevy pulled from git, unless they want to build the bevy example.
Replace ios specific cfgs with "apple but not macOS", dubbed
ios_and_friends, so that we also cover iPadOS, etc.. What those have in
common is that they don't have user-resizable windows. (We might want to
add visionOs in the future)
Also, simplify a few macos or ios cfgs with just target_vendor =
"apple", for what applies to all the operating systems.
In future versions of winit, it'll only be possible to create windows
when the active event loop signals availability. To upgrade to the latest
accesskit version as well as to run on iOS, we're going to implement support
for this earlier and stop using the deprecrated create_window() function
on the regular (not running) EventLoop.
Co-Authored-By: Olivier Goffart <olivier.goffart@slint.dev>
Similar to the wgpu access, the `unstable-winit-030` feature exposes a
`slint::winit_030` module, which in turn re-exports `winit` but also
provides access to the `WinitWindowAccessor` trait. The
`BackendSelector` is extended to provide a way to hook into window
attribute creation as well as providing a custom event loop builder,
similar to what `i_slint_backend_winit::BackendBuilder` provides.
The `require_wgpu_24` function accepts either a fully setup WGPU, or one
can configure individual aspects such as features/limits.
The wgpu_texture example uses this to add push constants to the required
features and thus eliminates the need for uniform buffers.
This adds a `unstable-wgpu-24` feature that exposes WGPU types in the
GraphicsAPI enum, adds `require_wgpu_24()` to the backend selector,
and adds a conversion from `wgpu::Texture` to `slint::Image`.
The `require_wgpu_24()` function in the selector will be extended in the
future (before the next release) to permit specifying additional aspects
of the WGPU configuration.
Co-Authored-By: Olivier Goffart <olivier.goffart@slint.dev>
With a previous PR, I added a hook to enable the creation of a winit window, which necessitated accessing the winit event loop (https://github.com/slint-ui/slint/pull/7227). This hook was removed in `cd29bdd367` because the Slint event loop was moved to `SharedBackendData`.
I'm very open to the possibility that this is not the correct change, perhaps due to one or more of the following
- Making `shared_backend_data` public
- The `unwrap()` calls
- The possibility that exposing `with_event_loop()` may be a better solution
In the future, the plain winit::event_loop::EventLoop won't be usable for window creation anymore. There are two places where we need it:
1. From places where we also have access to the shared backend data.
2. From the top-level create_winit_window() function.
The latter we have to eliminate in the future, so might as well do it now and clean up to have one thread local less.
This means the event loop spawning goes through the backend, which will permit for state from the Backend struct to be available when spinning the event loop even when spawning it merely.
The winit backend defaults to locating a canvas element with the id "canvas". After the parent commit, this id can't be overridden by the API, so we can remove the function parameters.
(The parent commit implements the override via an attribute hook)
This is a hacky approach, but does help a lot with the tedious fixes.
See https://rust-lang.github.io/rust-clippy/master/index.html#/unnecessary_map_or
```
__CARGO_FIX_YOLO=1 cargo clippy --fix --all-targets --workspace --exclude gstreamer-player --exclude i-slint-backend-linuxkms --exclude uefi-demo --exclude ffmpeg -- -A clippy::all -W clippy::unnecessary_map_or
cargo fmt --all
```
Add `with_default_menu_bar` to winit's `BackendBuilder` to permit applications
to provide their own menu bar.
Fixes the lsp's Window -> Keep on top menu on macOS.
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
In `winit`, it is not possible to instantiate a new window without access to the `winit` event loop, which Slint manages. With this change, there is now a `create_winit_window` call on Slint's winit` back end that will enable creating `winit` windows using existing functionality.
Of course, the utility of these windows is limited without access to `winit` event handling, but there are applications for which simply creating a window and instructing an external program to write into it (by passing the `HWND` on Windows or the `XId` on X11) is useful.
