Slint + async Rust = ?

[Tmpod]

Hello!

In a similar fashion to this post I made on CXX-Qt's discussions, I'm interested in knowing how Slint fairs with async Rust.

I've been interested in cross-platform GUIs for a while, particularly with Rust and QtQuick/QML. I discovered Slint at the beginning of last year, but haven't really dived into it yet. However, I'm quite curious, since it's made by Qt folks, is clearly heavily inspired by the modern QtQuick/QML system and has first-party support for Rust.

Async/await is becoming ever more prevalent, with many new API wrappers and the likes being published exclusively as async crates. One particular example I'm interested on is the great matrix-rust-sdk, which is now powering clients such as Element X iOS (Rust+SwiftUI), Element X Android (Rust+Jetpack Compose) and Fractal (Rust+GTK4). I'd like to play around with making a desktop client with Rust and either QtQuick/QML or Slint :)

How does using an async library like the one mentioned above in a Slint UI look like? Is there first-party support? If not, are there plans for such a thing?

On another somewhat related note, are there any major show stoppers in Slint in terms of feature parity with QML, specially with regards to accessibility and portability?

Thank you!

[hunger]

I have seen people use tokio with slint, but am no authority on how to do that. AFAICT you set aside one thread for the UI, pretty much like you would in Qt, too. Nothing Slint needs to support too much:-)

I have not really used Qt in a while, so I do not feel qualified to do a comparison -- but here is the Slint side of the picture:

Slint has support for accessibility, but this area could use some more work to make it truly great. In my experience that is the case with most accessibility systems out there though.

The limiting factor for portability of Slint is the rust compiler. In my experience all the interesting things are supported there, but some people will miss their favorite CPU architectures. Slint can be made to work pretty much everywhere the rust compiler can generate code for, it does not even need the full rust standard library. core and alloc are enough. Out of the box Slint will work on Linux, Mac and Windows, we have a list of supported MCU platforms and Android support is in the works.

Language portability of Slint is very good IMHO: We officially support Rust, C++ and JS as business logic languages and are currently adding python into the mix. A community member has used Slint from C#. We are of course always open for more languages:-)

The Slint language itself has a very strict separation between business logic and UI. I like that a lot. Basically a designer can design to his hearts content and a developer can refactor the code as needed -- as long as the interface between UI and business logic stays untouched, they will not break each others work. It also will allow us to have great tooling (soon;-) and makes support for so many different languages possible.

I am sure compared to Qt we do miss out on features. Most of that is by design: We happily delegate to rust infrastructure (e.g. docs, build tooling, etc.) and other people's crates (== rust libraries). Of course we also have features missing simply because nobody had the time to implement them yet. In my experience most bases are covered, as we tend to focus on those area the most people report issues in;-) And contributions are always welcome, too.

I hope this helps at least a bit.

[Tmpod]

Thank you for such a detailed response!

[ogoffart]

For async, Slint can run future in the UI thread with the slint::spawn_local function.
With that function you can spawn future and call async function from a callback handler, for example.

You can also run other async executor (eg, tokio) on another thread. It is fairly easy to call back into the ui thread with slint::invoke_from_event_loop.

[Tmpod]

I've tried it, and yes that works as well, thanks!

I saw that, and was giving it a shot, but it still requires the Tokio spawned future to be Send (which isn't possible with Rc). How did it work for you?

[bjorn]

It worked for me, because I did not need to pass a reference to my app in the Tokio future. It sufficed to await the Tokio task, and to only refer back to my app and its models from the async block passed to slint::spawn_local. I think this would be commonly the case.

Unfortunately my patch wasn't very polished yet so I can't yet link to my code for reference.

[Tmpod]

I see. I took a better look at your code and I think I understand why you didn't have issues: you create a client on each interaction, inside tokio's spawn block. (example)

In my case, I want to have a long lived client object (actually managed by an external crate) which provides async methods I need to call inside a tokio runtime.

[Tmpod]

I didn't end up doing much yesterday, but I ended up cooking this, which is working (compiles and runs):

let ui = AppWindow::new()?;
let app = Arc::new(App { client: make_client() });

ui.on_foo({
    let ui_weak = ui.as_weak();
    let app_ref = app.clone();
    move || {
        let ui = ui_weak.unwrap();
        let app = app_ref.clone();
        let _ = slint::spawn_local(async move {
            let foo = tokio::spawn(async move { app.client.foo().await }).await.unwrap();
            ui.set_foo(foo.into());
        });
    }
});

Where App is just a struct with some APIs wrapper client.

However, this feels a bit clunky and with too many Weak/Arc clones. Can this be simplified?
I've also made some macros to heavily simplify this in terms of syntax, but I was looking to simplifying the logic itself.

[Tmpod]

I'm having issues with another thing, though: changing UI from within tokio tasks (through slint::invoke_from_event_loop).
Specifically, the API client I'm using requires their event handlers to be both Send and Sync, and it seems Weak isn't the latter, so I can't get a weak ref for the UI component inside the closure. How can this be solved?

Edit: Sorry if I'm hijacking this thread way too much! Let me know if I should create a new one.

[maxenko]

Just to add to above example, as it took a bit to wrap my mind around.

    runtime.clone().on_state_change.lock().await.subscribe({
        let ui_handle = ui_handle.clone();
        move |state| {
            let ui_handle = ui_handle.clone();
            slint::invoke_from_event_loop(move || {
                let ui = ui_handle.clone().unwrap();
               // do stuff with ui...
            }).unwrap();
        }

    }).await;

Here I queue up a lambda that will be invoked from a different thread to be run on main UI thread. This is more or less identical to how WPF dispatches calls from other threads on main ui thread (through a message queue). Make sure you are not sending ui handles to methods with Sync traits (as Slint is not multi-threaded).

In short, there are no issues spawning threads from main UI thread, or having parallel threads make calls to slint ui.

[Tmpod]

Nice, thank you for the extra snippet! For the project I'm working on, because of all the repetitiveness and verbosity of this approach, I made some macros that greatly simplify callbacks and so on. I'm still not 100% sold on them, but they're here: https://git.sr.ht/~tmpod/eigen/tree/main/item/src/utils.rs

[Tmpod]

(apparently replies via e-mail don't get added to the existing comment thread :/)