Call for Testing: Slint 1.12 is Almost Here

[ogoffart]

We're preparing to release Slint 1.12, and the nightly builds are ready for testing. Your feedback helps us catch bugs early and improve the final release.

Highlights in 1.12

• 🎮 WGPU integration - including support for Bevy
• 📱 Initial iOS support
• 🎨 Design token export from Figma plugin to .slint files, plus palette support in the live preview's color picker.
• 🧰 New console panel in the live preview
• 🪟 Feature to exposes winit types
• And more - see the full ChangeLog.

👉 For testing instructions, see the nightly release

Found a bug? Have feedback? Let us know through GitHub issues or Discussions.
Your input helps us make Slint better for everyone 💙

[ubruhin]

A quick test with LibrePCB didn't show any obvious problem with 1.12 👍
My only remark would be that mouse-drag-pan-enabled is a quite long and complicated name 🙈

[ogoffart]

Thanks for testing it out 🙏
Yeah, we spent quite some time discussing the name. mouse-drag-enabled was proposed too, but we chose the longer one as it is more accurate. What would you suggest?

[ubruhin]

Hmm good question. My biggest criticism would be that "drag" and "pan" is kind of redundant IMO, thus one could just remove one of them, e.g. ending up with mouse-pan-enabled. Also I wonder if the property also controls panning on a touchscrean where "mouse" would be kind of misleading as panning would be done by finger.

Other ideas:

• pannable (is this an english word?)
• pan-enabled
• interactive-pan
• draggable
• drag-enabled

A lot of potential for bikeshedding 🙈

[tronical]

We figured that panning can be done - generally - by finger motion, mouse wheel, or by dragging the mouse. The property in question here is only about enabling the user to pan by dragging the mouse.

(Just as some background information as to why we thought this was a good compromise)

[ubruhin]

Alright - in the end it's just a name, not worth to spend too much time for discussion ;)

[ubruhin]

Btw, it seems Slint (respectively its dependency bevy_a11y) now requires at least Rust 1.85. Since we use a custom Docker image to build LibrePCB on Windows, this enforces us to build a new image...

Bevy seems to be a game engine, do we really need this dependency? 🤔

In https://github.com/slint-ui/slint/blob/master/docs/building.md there's still Rust 1.82 mentioned as minimum requirement.

[tronical]

This is a dependency just from the bevy example in the workspace, it's not a slint dependency directly. I think once the release is out and your container uses slint from crates.io, that implicit dependency will disappear.

Edit: oops, what I wrote doesn't make sense, since you're using C++. Hmmmm. So bevy_a11y should not be an actual dependency built, but it's true that the rust version requirement remains for C++ :(

[ubruhin]

Hmm I see. We include Slint as a Git submodule because we need a few patches in CMake & Cargo configs. So then I might need to check how we can get rid of unneeded dependencies (possibly by applying more patches).

[ubruhin]

So bevy_a11y should not be an actual dependency built, but it's true that the rust version requirement remains for C++ :(

At least it seems to be downloaded. I just found out this problems when our CI run with Slint 1.12 which failed then (logs). There you can find this output:

Downloaded bevy_a11y v0.16.1

which then failed:

error: failed to parse manifest at C:\\__w\\_temp/cargo-home\\registry\\src\\index.crates.io-6f17d22bba15001f\\bevy_a11y-0.16.1\\Cargo.toml
Caused by:
feature edition2024 is required
The package requires the Cargo feature called edition2024, but that feature is not stabilized in this version of Cargo (1.83.0 (5ffbef321 2024-10-29)).
Consider trying a newer version of Cargo (this may require the nightly release).
See https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#edition-2024 for more information about the status of this feature.

EDIT: It's not a blocker for us, we can update our Docker image. It's just inconvenient and also undesired to have unnecessary dependencies.

[ogoffart]

It turns out this is not easy to fix unfortunately
So we're going to require Rust 1.85 for C++ in this release.
#8659

This is unfortunate that in order to get the metadata we need to download all the crates required for the full workspace including examples. I couldn't find a way to prevent that. Maybe we need a way to "patch" the top-level Cargo.toml or disconnect the slint-cpp from the workspace.