QtConcurrent Support
jlgerber opened this issue · 4 comments
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.
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):
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. 👍
Agreed. i posted the request before rigging that up. Out of curiosity, have you done any experiments with rust async and rust-qt coexisting?
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.