I always see new GTK apps popup on Flathub. I dont really care and think GTK looks fancy, although CSD suck a bit and they waste space and often functionality.
But they work, are solid, and do what they should.
Qt on the other hand may seem more like a complex job to code with. I dont actually think so, but I heard especially writing rust with GTK is way better than with Qt.
I like KDE a lot, and even though I am excited for Cosmic I think Qt is the better toolkit for many things and a lot of time. But Dolphin seems to suffer from memory safety issues all the time, as well as other projects.
Do you have experience in rust, using GTK or Qt? How do they compare?
C bindings and APIs generally work much better in Rust because the language works a lot more like C than it does C++.
Qt depends a lot on C++ class inheritance, and even does some preprocessing of C++ files to generate code in those classes. That’s obviously not possible when using Rust. And it looks like you need a fair bit of unsafe there and there to use it at all too.
Meanwhile, GTK being a C library, its integration with Rust is much more transparent and nice.
So if you’re making a GUI Rust app, you’re just kind of better off with GTK at the moment. It’s significantly easier and nicer.
Having made the choice to use GTK for a Rust project years ago - before a lot of the more Rust-friendly frameworks were around - this is exactly why I chose it. Nothing to do with DEs or any of that, just looking for a better coding experience. Now I’d probably choose one of the several Rust-focused solutions that have popped up though.
Iced and Floem are the ones I’m seeing used on larger rust only applications.
GTK is in bare C
, which is rather easy to interop with Rust
. Even if using GLib from Rust is a pain, GTK can and does have decent Rust bindings.
QT on the other hand is C++ with object oriented stuff, and therefore cannot have easy bindings to Rust.
Could you explain C bindings in Rust to a nonprogrammer? Does this mean GTK can’t use Rust natively, at least for the interface?
Bindings are like translations of the relevant C code to Rust so they can use Rust to talk (interop) with the C library instead of having to use C.
Does this mean GTK can’t use Rust natively, at least for the interface?
I never used GTK, but I suppose from this conversation that yes.
GNOME was focusing on building Rust bindings for GTK for many years before Qt development picked up. The GTK bindings were usable within a year or two after Rust’s 1.0 release. Yet even today, those looking to build applications in Rust will find that GTK is the only mature toolkit right now. And if you’re doing that today, I’d recommend starting with Relm4 for the best GTK Rust experience.
Rust does not support the C++ ABI, and Qt does not provide a C interface, so much work has to be done on building the tooling for binding C++ libraries to Rust. That work is still ongoing, so some have opted to use QML instead of interfacing with Qt C++ libraries. Yet if you’re looking to use Qt or QML, you may as well use Slint instead. It’s developed by former Qt/Trolltech developers and has a similar approach as QML.
I think there’s a pretty big thing here that people are kinda missing and it’s the ease of app creation. Recently gnome has done a lot for app developers to make the experience really good. Workbench, gnome builder, biblioteca all combined with the ease of libadwaita and the gnome circle make app development significantly easier for gtk than qt. There’s a big community now with a lot of inertia. I think workbench has around 100 tutorials now or so. Super low barrier to entry. Also libadwaita is pretty.
I already use gnome now, but even before I had settled on a DE, I took a look at both ecosystems and was heavily leaning towards gtk because of all these factors and against qt because of its reliance on c++. Until all of those factors are replicated well for qt (and by extension kde), I don’t think they’ll see the same level of development.
a few reasons I think, the QT bindings are split between cxx-qt and qmetaobject-rs . Neither of which are super great IMO, but even if they were, we have UI frame works like slint and egui which are already becoming quite good, slint has a good native look that resembles QT so people wanting that design can use that instead.
slint has a good native look that resembles QT
It doesn’t just resembles QT, it uses QT as backend.
Damn, thanks for the tip! So does it support native KDR Styling and all too?
Could in theory Apps like Dolphin be entirely rewritten in Rust, using Slint as Frontend, and still be native in KDE?
From their github:
NOTE: When Qt is installed on the system, the native style uses Qt’s QStyle to achieve native looking widgets.
I’m not that familiar with KDE’s styling, but if I remember well it should just be a Qt style, so it should work.
Regarding rewriting Dolphin, I think in theory you could do that, in practice it’s probably pretty challenging given the amount of features Dolphin has.