search

rust-qt / ritual

Use C++ libraries from Rust
Apache License 2.0
1.22k stars 49 forks source link

QtConcurrent Support #93

Closed jlgerber closed 4 years ago

jlgerber commented 4 years ago

This would be great to get support for, as I dont think there is a way without custom signals to do meaningful work outside the main thread and update the gui when done.

https://doc.qt.io/qt-5/qtconcurrent-index.html

jlgerber commented 4 years ago

Meanwhile, i have come up with a solution to doing work outside of the main thread that doesn't require any custom qt. (but be forewarned, its a bit hacky, relying on QObject's name_changed signal):

conductor

Riateche commented 4 years ago

I don't see anything particularly useful in QtConcurrent. Rust already has superior async features. Custom signals will be implemented some day.

Your temporary solution seems fine. :+1:

jlgerber commented 4 years ago

Agreed. i posted the request before rigging that up. Out of curiosity, have you done any experiments with rust async and rust-qt coexisting?

Riateche commented 4 years ago

Custom signals are now implemented, and there is no immediately obvious reason to support QtConcurrent right now, so I'm closing this issue. Please comment if you have a use case that requires it.

I was thinking more about passing arbitrary data across threads with Qt signals. If you only have one receiver, a simple solution is to use a normal MPSC channel from std (or a crossbeam channel) for passing actual data, and use a Qt signal without arguments simply for signaling to the receiver that a new item is available in the channel.

I didn't do any async Qt stuff yet. I'm planning to put together some kind of example that uses tokio and see how it looks like. All async work will most likely have to happen in a separate thread or thread pool, and communicating to the main thread managed by Qt can be done with async channels and Qt signals.