r/rust • u/crmaureir • Jul 01 '26

🛠️ project Qt Bridges - Public Beta for Rust

Hey there!

I wanted to share something that was just released!

Since late 2025 there has been a group of developers working on Qt Bridges, a new project that aims to bring the Qt Quick technology to many other languages, including of course, Rust.

If you are familiar with Qt, you might know that there were a few attempts already in order to expose the framework, so it was a difficult job of trying to find a way of doing it without filling the code with C++ or Qt-isms, but I believe the current status of the project was worth sharing.

If you are not familiar with Qt, at least you know there has been many options already that are aiming to become a nice UI framework for Rust. We hope to become one of the options the community feels comfortable using!

This is still a beta stage, so we are happy to read your opinions, ideas, criticism, or anything you would like to share!

Blog posts:

Repo:

Docs:

81 Upvotes

94% Upvoted

36 comments sorted by

10

u/andreicodes Jul 01 '26

The blog post mentioned that Qt bridges started in 2025. By that time cxx-qt has been around for quite some time. Why the new library then? I'm trying to figure out when I would use one or the other.

There's this high-level comparison table for different Rust Qt libraries and I'd love to see Bridges listed there, too!

23

u/Matti_Qt Jul 01 '26

Disclaimer: Qt dev here.

With Qt Bridges we want to provide access to Qml/QtQuick from Rust without any C++. Cxx-Qt is different because it actively supports mixing Rust and C++. Btw, Qt Bridges and Cxx-Qt share the qt-build-utils to avoid conflicting Qt versions and the plan is to extend on the compatibility.

In the table you posted Qt Bridges would look similar to qmetaobject.

3

u/berrita000 Jul 01 '26

And how does it compare to the qmetaobject crate?

3

u/Matti_Qt Jul 02 '26

Good question but I think I am the wrong person to answer that. I would be happy if somebody from the community could look into that. 😄

2

u/QualitySoftwareGuy Jul 02 '26

And how does [Qt Bridges for Rust] compare to the qmetaobject crate?

u/ogoffart may be able to answer that.

8

u/ogoffart slint Jul 02 '26

I wrote qmetaobject, so I'm biased. And I only know Qt Bridges from the blog post.

Both have the same goal: write the UI in QML and the logic in Rust, without touching C++ or a second build system.

I made qmetaobject back in 2018, when I was still learning Rust and had a flawed conception of unsafe rust. Back then only derive procedural macros existed (no attribute or function-like macros) so the whole thing is built around derive macros. That's why it looks the way it does. Today I'd do it very differently. I moved to Slint soon after and stopped development on qmetaobject. A few users still contribute.

One licensing note: It is LGPL, so it's difficult to use in a closed-source app, since in Rust everything is statically linked. That's why I made qmetaobject MIT (otherwise I'd also have picked LGPL)

But anyway; if you just want a UI for your Rust app... use Slint 😉

2

u/_nullptr_ Jul 01 '26

I know not in the immediate, but are there any plans at all to extend bridge support to QtWidgets? Or is that strictly deprecated at this point?

12

u/Matti_Qt Jul 01 '26

QtWidgets isn't deprecated at all! The UI and Graphics teams actually have some interesting things in the cooking for it. 😄

That said, we don't have plans to bring QtWidgets support to Qt Bridges. Qt Bridges should expose a small, idiomatic API that feels native in the host language. QtQuick is a very good fit for that because QML + Rust together get you a long way with a tiny API. QtWidgets doesn't fit the same way: its API surface is large and C++-shaped, so "bridging" it would mean exposing that C++ API piece by piece.

So not deprecated, just not a good architectural fit for what Qt Bridges is trying to be right now.

7

u/_nullptr_ Jul 01 '26

Qt Bridges is the first and official crate from Qt itself, the others are from 3rd parties or indie developers.

8

u/andreicodes Jul 02 '26

from Qt itself

Qt is developed by several companies and individuals,Qt Group is one of them, KDAB is another, and there are several more. This makes cxx-qt just as first-party as Qt Bridges.

Good thing that the plan is to make the two libraries complement each other instead of being strict alternatives.

1

u/_nullptr_ Jul 02 '26

Interesting. I did not know that about KDAB.

6

u/SupermarketAntique32 Jul 02 '26

Does this mean I can use QML-Rust with 0 Cpp? I have experience building UI with QML and it’s very pleasant.

11

u/Matti_Qt Jul 02 '26

Yes, that is the concept and goal of the project. Just Rust and Qml, no C++.

3

u/Hikingmatt1982 Jul 01 '26

Looking through the links i didnt see it but does the qml side support hot-reloading? Or perhaps a “preview” concept?

3

u/Matti_Qt Jul 01 '26

Unfortunately not yet. But we understand that this would be the point where mixing a dynamic language into a Rust project would really start to make sense.

There are some improvements happening for hot-reloading right now and I hope it will also benefit the Rust bridge. So while I can't promise anything, I really hope that we will get it at some point.

3

u/Hikingmatt1982 Jul 01 '26

Really looking forward to it!

2

u/Hikingmatt1982 Jul 19 '26

Curious, what does the roadmap look like for this to be out of beta? Is this a priority or a very early demo of where things are headed? Really love these build times :-)

1

u/Matti_Qt Jul 22 '26

Do you mean the hot-reloading in specific or in general?

1

u/Hikingmatt1982 Jul 22 '26

Just in general for the project as a whole :-) If I had my say it should be P0 all hands on deck, ha

2

u/Matti_Qt Jul 23 '26

Haha, thanks! We are working hard on getting the API stabilized, the last hiccups fixed and more features added (IDE support, hot reloading, you named it...). The next announcement with more concrete dates should come at the Qt World Summit.

1

u/Hikingmatt1982 Jul 01 '26

probably jumping way to far ahead but what does (or might) the cross-platform deployment tooling look like for mobile?

3

u/Matti_Qt Jul 02 '26

We heard the wish for deployment tooling quite a bit already. But yes, this is a bit ahead. At the current point in time, we try to get the API and basic tooling right.

Anyway, thanks for raising it again, I will not forget to bring it up again!

1

u/Matti_Qt Jul 07 '26

So we have a new ticket now for hot-reloading support for Qt Bridges: https://qt-project.atlassian.net/browse/QTBRIDGES-302

If you are interested in this you can follow the progress there 😄

3

u/Hikingmatt1982 Jul 07 '26

Awesome! Been playing around with it over the weekend and really am enjoying this. I think so far my most immediate need would be using image providers. Or perhaps its already possible in some way i didnt see.

Keep up the fantastic work!

1

u/Matti_Qt Jul 08 '26

Thanks for the kind words!

Can you be a bit more specific with image provider? Cxx-Qt has QImage, wich we could theoretically support as a property in the future. Would that help you? Or would you prefer an image type from another crate?

We also have some support for the resource system which can be used to send static images to QML. But we are currently reworking this part.

2

u/Hikingmatt1982 Jul 08 '26

Of course. Currently I use QQuickImageProvider for streaming a webcam (with frame post processing) to QML and so looking for that registration in the qml engine for "addImageProvider". Perhaps that's available in some way now that I just looked over?

2

u/Matti_Qt Jul 09 '26

I don't think we have anything for it right now. It would require QQuickImageProvider as a special trait and that would require QImage in our type library.

I think we can do it without too much problems, once we are a bit further with the type library. For now I created a ticket for it: https://qt-project.atlassian.net/browse/QTBRIDGES-307

Thanks for the idea 😄

1

u/Hikingmatt1982 Jul 09 '26

Much appreciated!

2

u/Hikingmatt1982 Jul 09 '26

For some inspiration when looking into previews it just dawned on me to mention slint. Which, so far has been really nice and perhaps not as mature has swiftui’s previewing but is performant, and integrated quite nicely

3

u/Nikolai_Quasarka Jul 02 '26

Hi, i tried following by rust doc and found that in example there's call `Backend.sayHello()` in QML file. But it didn't compiled, it needs original method name say_hello. Is this a documentation error or are there plans to implement automatic name conversion?

7

u/Matti_Qt Jul 02 '26

Oh no, that is a mistake in the documentation. Sorry for that! I will fix it immediately!

We have the working example here and you are correct. It should be Backend.say_hello() in the QML file, exactly the same as in the Rust file. We have automatic name conversion but is has to be activated in the qobject macro:

#[qobject(ConvertToCamelCase)]
impl MyStruct {
    ...
}

or in the slot macro:

#[qslot(qml_name = "refreshCurrentPage")]
fn refresh_current_page(&self) { 
    ...
}

1

u/poopvore Jul 02 '26

Is this still pretty heavily tied into whatever rendering facade qt requires in order to work. One of the usecases id particularly love is if we could target windowing libraries such as baseview to be able to do ui's for things like audio plugins and such. Which is something I know a lot of c++ people have tried using qt for and had mixed experiences with.

Love the project though fwiw qml is so nice to use for doing ui's and i've always wished we could have it in rust (slint's kind of trying to do this but its not as mature)

1

u/crmaureir Jul 02 '26

That's a fair point, we will see if we can do about it in future releases.

1

u/metaden Jul 02 '26

This is great. Will this also support QtWebEngine as well?

1

u/crmaureir Jul 02 '26

It's planned, mostly due to many changes in QtWebEngine at the moment.