cxx-qt

I've been experimenting (thanks to Claude Code because it removes the headache drastically for me of Rust nuances, I'm not a Rust expert by any means) with Qt and Rust. I discovered cxx-qt which is maintained by some Qt maintainers, which are all employed at KDAB. I had no idea KDAB or this project existed. It's been very smooth so far. I can honestly say the barrier to building a GUI is very low with Claude, must to the dismay of others, but it beats me building an Electron app. https://github.com/KDAB/cxx-qt

> In the previous C++ version, I used Qt, which might seem very strange for a server software, but I wanted a nice way of doing asynchronous I/O and Qt allowed me to do that. It was callback-based, but Qt has a lot of support for making callbacks usable. In the newer prototypes, I used Go, specifically for the ease of networking and concurrency. With Zig, I was stuck. There are new Qt bindings for these. Go has https://github.com/mappu/miqt and Zig has https://github.com/rcalixte/libqt6zig. I wonder if the author knew about them. I don't know enough about either language to speak on the async parts. For me, I want these for Rust, especially what Zig has because I use KDE. I know about https://github.com/KDAB/cxx-qt and it is the only maintained effort for Rust that is left standing after all these years. But I don't want QML. I definitely

> [1] https://areweguiyet.com/ The only mature cross-platform UI frameworks I see in this list are written in C and C++ :) And of all the various Rust bindings for Qt, only a single one ("ritual") offers bindings to the Widgets API. Not only are these bindings unsafe, the project has also been abandoned. https://github.com/KDAB/cxx-qt/?tab=readme-ov-file#compariso.... Of course, this is not suprising, given that the API surface of Qt6 is huge and difficult (or impossible?) to safely wrap in Rust. (The reality is that Rust's ownership model makes it rather awkward to use for traditional UI frameworks with object trees.) Tauri looks neat, but the actual UI is a webview, so it's not everyone's cup of tea. (Certainly not mine.) As you said, egui is cool for simple tools, but not suitable for complex desktop applications. Yes, Rust has gotten

> I worry that they don't really accurately reflect real world closed source experience because of the inherent selection bias. As opposed to what, yet another beginner React app? That’s what everyone seems to be testing with but none of the projects I’ve seen are reflective of a production codebase that’s years old and has been touched by a dozen developers. Throw it at a complicated non-frontend mixed language repo like cxx-qt [1] or something, preferably where the training data doesn’t include the latest API. [1] https://github.com/KDAB/cxx-qt

My employer, KDAB, is building an excellent Rust binding for Qt: https://github.com/KDAB/cxx-qt

- https://github.com/woboq/qmetaobject-rs - https://github.com/KDAB/cxx-qt/

I second this. I wrote an internal Qt/QML app that ran on Windows, Linux, Android, and Raspberry Pis. We had ~20 Raspberry Pi's running this app in kiosk mode. If only KDAB/cxx-qt[1] were ready then, I would have done as much as possible in rust . - [1] https://github.com/KDAB/cxx-qt/

> I have searched high and low for something better, here is one rabbit hole: https://www.areweguiyet.com I'm very interested in the KDAB/cxx-qt path from that page: https://github.com/KDAB/cxx-qt Once they get Arm & Android coverage, that'll be my go-to solution. Rust for all business logic and remote synchronization. Qt/QML for display with accessors into the Rust model.

There is an example folder https://github.com/KDAB/cxx-qt/tree/main/examples