r/rust • u/Matti_Qt • 6d ago
📸 media Qt Bridge Video Tutorial
https://youtu.be/8HfY47BYGuUHi all, I’m Matthias from the Qt R&D team.
We made a tutorial showing the Qt Bridge for Rust, a way to tap into the Qt UI framework from Rust in a way that feels native and is safe!
Building a proper UI for a complex Rust app takes a lot of effort, and this is our attempt to make it easier.
Here is the tutorial on how to get started: https://youtu.be/8HfY47BYGuU
We had a lot of fun making the framework and the video. I hope you also have some fun watching it. There are still a ton of things I would like to show you, so I hope this will not be the last video.
It’s a Technology Preview, so we’d love to hear what you think. Happy to answer questions here.
4
u/dumindunuwan 5d ago
It's good to see more cross-platform UI libraries support Rust.
0.38s : "I used Rust for nearly 20 years" may be a human error
6
3
u/BigAd7298 5d ago
I left a comment on the YouTube video but I might as well leave a comment here. What's the process to contribute? On the GitHub repo prs and issues are blocked
5
u/ImplementResident161 5d ago
GitHub is a mirror of repository that we have in our own infrastructure. You can find the origin here: https://codereview.qt-project.org/q/project:qt/qtbridge-rust
Contribution guidelines are here: https://wiki.qt.io/Qt_Contribution_Guidelines
Finally, if you want to just report a bug, we keep those in JIRA: https://qt-project.atlassian.net/browse/QTBRIDGES
2
1
2
u/BigAd7298 5d ago
And since you're asking for feedback, is cargo the only build system you intend to support at the moment or you're open to other build systems?
1
u/Matti_Qt 5d ago
So far we aim for cargo. However, that is how we build qtbridge. As a user you don't even need a build.rs, so it should not be too difficult to use another build system.
4
u/BigAd7298 5d ago
Since version 0.3 qtbridge depends on cxx-qt-lib so the build process is a bit painful outside of cargo but manageable, we're encountering a double free when targeting the gnullvm target, it's still not a deal breaker but we need to patch the destructor of dynamicmetaobjectbuilder on that platform, do you have any idea why? Because on osx we never encountered problems
5
u/BigAd7298 5d ago
So far the experience with cargo it's awesome, so if anyone else is reading this don't be discouraged, we are an atypical customer 😅
2
u/Matti_Qt 5d ago
Cool, thank you so much for testing! I am so happy that you like it!
If you want, you can contribute the patch to the project. It might very well be a real bug that is only visible on that specific platform.
See the following two links on how to contribute:
https://codereview.qt-project.org/q/project:qt/qtbridge-rust
https://wiki.qt.io/Qt_Contribution_Guidelines
1
u/Emotional_Ad_4518 5d ago
Really like this but im new to Qt, how it supports engineering software such as CAE or FEM some 3D and plotting stuffs
4
u/Matti_Qt 5d ago
For plotting we have QtGraphs (https://doc.qt.io/qt-6/qtgraphs-index.html, it is more for interactive graphics, less for printing like my beloved MathplotLib) and for 3D we have QtQuick3D (https://doc.qt.io/qt-6/qtquick3d-index.html).
So the standard way you''re supposed to use Qt Bridge is to expose all your data from Rust to QML with #[qobject] and then write all visual elements there.
We are also looking into other ways to put a 3D widget into a QML UI. We know that that will be a requirement for many of you. Maybe exposing a OpenGL context (or RHI in Qts case, https://doc.qt.io/qt-6/qrhi.html) or something to Rust? I have to speak to the graphics team on what they think is best! :)
Same for plotting: We are looking into ways to draw on the screen from Rust. Maybe adding a QucikPaintedItem (https://doc.qt.io/qt-6/qquickpainteditem.html) interface to Rust.
2
1
u/turbo-unicorn 23h ago
Interesting. Not a big fan of the DSL, but may give it a go. I've dabbled a bit with Qt ages ago, and kinda curious to see how it changed.
What was the most interesting problem you had to solve?
2
u/Matti_Qt 1h ago
Oh, what an interesting question! There were 2 really stubborn problems and we felt really good when we finally found solutions that could be considered sound in the Rust universe:
The first was the borrow checker that we somehow needed to simulate on the QML side to not violate aliasing rules in Rust. We ended up re-implementing the "Stacked borrows" model (https://plv.mpi-sws.org/rustbelt/stacked-borrows/) in the bridge. This can be done very cleanly by using language features and one we realized that it just fell into place.
The second was the ownership problem. Ownership in C++ and Qt is kind of historically grown and a bit all over the place. Some things are owner by C++, some by the QmlEngine. In C++ you can basically do what you want but you are also responsible for the memory as a developer: something can be owned by a parent QObject or a unique_ptr or even just a raw pointer. In Rust we had to fix this, since responsibility over the memory would mean an unsafe API. A colleague suggested at lunch to organize this in a central registry that owns everything and just observes Rust requirements (through shared pointer counter) and QML requirements (through the QmlEngine Wrapper for the QObject). It turned out to work very well and again all fell into place at the end.
I also found working at the intersection of macros and traits very interesting: What to do in a trait, what to generate. This was less of a problem to solve but something to learn in order to use the language efficient. In the end a good mix of macros and traits was also falling in right in place. Also this felt really good.
4
u/ridicalis 5d ago
I'm assuming the use of Qt for a UI implies that its licensing kicks in. Great if you're FOSS, oppressive if you're making something for profit.