KDAB Launches CXX-Qt To Provide Safe Rust Language Bindings For Qt

[phoronix]

Phoronix: KDAB Launches CXX-Qt To Provide Safe Rust Language Bindings For Qt

KDE/Qt-focused consulting firm KDAB has been developing CXX-Qt as a new project to improve integration of the Rust programming language with the Qt toolkit...

https://www.phoronix.com/scan.php?page=news_item&px=CXX-Qt-Rust-Bindings

[tildearrow]

What? MOC being brought to Rust?
That sounds impractical...

[oleid]

Of only qml would provide all the features the bare toolkit providers.

[mether]

What? MOC being brought to Rust?
That sounds impractical...

GTK has good Rust bindings based on gobject. The glue code might look a bit odd with MOC but it is entirely possible to provide reasonable bindings.

[tildearrow]

GTK has good Rust bindings based on gobject. The glue code might look a bit odd with MOC but it is entirely possible to provide reasonable bindings.

The biggest reason why it's more difficult for me to work with Qt is its MOC.
When writing code using Qt, I have to use the Qt dialect of C++ (which adds a few things like "Q_SIGNALS:", private/public types/scopes, Q_OBJECT, STL-style extension-less headers, foreach (but thankfully C++-style for a: b is replacing this) and emit), and then this code is compiled to proper C++ before being consumed by the compiler.
When using GTK or any other toolkit, the code doesn't go through any pre-compilation and it's pure C++.

Only Qt Creator and KDevelop support the Qt C++ dialect correctly, whereas VSCode and Vim don't.

If something like the Qt approach were to be put into Rust, that would create a mess considering it has a standard project system (Cargo).

[ssokolow]

For a moment, I was actually excited... but then... this is worthwhile as an alternative to qmetaobject-rs... how?

I quite literally just tried QML for the first time yesterday and I'm not impressed at how much work it takes to wrestle a Qt Quick 2 desktop application into feeling somewhat native, rather than like a smartphone app running in an emulator.

...and that's with me going into it knowing that the offered set of widgets and classes is very incomplete and skewed toward what a phone app will want compared to the QWidget APIs. (The last time I was considering something QML might be suited for, it turned out the StackLayout QML type is too new to be in the Qt 5.12.8 distributed with Kubuntu 20.04 LTS, so I stuck with QWidget and QStackedLayout.)

At least a web app will automatically get the appropriate scrolling behaviour on desktop or mobile browsers when you say "this region is scrollable", unlike Qt Quick 2's ListView.

(The only reason I even bothered to use QML+Rust rather than going straight to PyQt or PyQt+rust-cpython is that the project's only use for a GUI is a way to glue together "ATi Remote Wonder II fakes being a keyboard" and "the Rust ttspico crate has lower latency for TTS than my usual approach of running festival --tts as a subprocess" for a "Let me build a new 'fall asleep' playlist without getting out of bed" tool.)

[zxy_thf]

Only Qt Creator and KDevelop support the Qt C++ dialect correctly, whereas VSCode and Vim don't.

If something like the Qt approach were to be put into Rust, that would create a mess considering it has a standard project system (Cargo).

Potentially Rust's function attribute system can be used/abused for this purpose.

[dremon_nl]

The biggest reason why it's more difficult for me to work with Qt is its MOC.

You can use Qt without moc using 3rd-party header-only project: https://github.com/woboq/verdigris.git
I already wrote in another topic some pros and cons of using Qt based on my experience which spans many years. The major cons are (when used with C++):
* It forces you to adopt QObject-based asynchronous model with ownership which is very fragile and endless source of memory issues in bigger projects
* It's for all practical purposes C++-only (I don't consider Python to be a serious language for production application). C++ sucks. I can tell that as a former C++ developer with decades of experience.
* It's all or nothing, a huge framework which you have to deploy with your application including multiple large DLLs, a bunch of plugins, resource files and whatsnot.
* Qt WebEngine is a major pain in the ass. Unstable, requires some black magic to make macOS bundles to be notarized by Apple (otherwise it fails with some security warnings)
* It's impossible (or extremely hard) to customize Qt for particular needs and build that custom version from sources
* It's very hard to do cross compilation with Qt which severely limits CI/CD

Some pros:
* Extremely easy to make layout-friendly UIs in no time, using graphical designer
* Qt Creator is a good C++ IDE with Qt integration
* Native-looking cross platform
* It is a native framework on Linux so no GTK dependency

[ssokolow]

Some pros:

You neglected to mention that it's the only toolkit on Linux that doesn't either feel like a refugee from the 90s, both visually and Unicode-wise, or force you to contort around GTK's minefield of half-baked APIs and increasing efforts to deprecate non-GNOME look and feel.

(About two weeks ago, I prototyped a hotkey binding GUI for QuickTile, which uses GUI-less PyGObject to bind to libwnck and python-xlib to access XGrabKey and, dear God, I'd forgotten what a janky mess GTK APIs were compared to PyQt... let alone that I had to give up on newer additions like Gtk.ShortcutsWindow because they're hard-coded to ignore my platform settings and be inconsistent with other Gtk.Window subclasses by force-enabling CSDs and window shadows.)

[dremon_nl]

You neglected to mention that it's the only toolkit on Linux that doesn't either feel like a refugee from the 90s, both visually and Unicode-wise, or force you to contort around GTK's minefield of half-baked APIs and increasing efforts to deprecate non-GNOME look and feel.

Actually there is wxWidgets which we are currently using in our desktop Rust application. With some small custom C++ bridge code.
On Linux it uses GTK (you can choose between GTK2, GTK3 or even GTK1 I think). But it's abstracted away so no need to deal with GTK APIs.

The reason is that there is no stable GUI widget library for Rust yet. So either HTML/CSS/JS, Qt or wxWidgets. And web is not really made for desktop apps. I have yet to see a decent web-based desktop application with complex UI which doesn't suck. It's either VS Code-like editor with primitive unusable dialogs or some sort of chat app.