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.
Any examples of such rust-focused solutions that popped up?
Iced and Floem are the ones I’m seeing used on larger rust only applications.
With Cosmic, Iced seems like it will become a great Framework!
Agreed! For something as controversial as making another new DE (RIP Unity 7), it’s coming along very nicely.
I can’t wait to try cosmic once it’s ready.
For a DE to succeed it just has to succeed over lots of alternatives in some features.
GNOME
is widely developed and protected, as it is the default on Fedora (with Redbat) and Ubuntu (Canonical). It is kinda fancy but its main focus seems to be a new “material-ish” simplified and streamlined Desktop.
Just not with transparency, thin animations, blur, 3D Backgrounds, an actually working, goodlooking and existing panel/dock, Apps that actually use your huge top bar used for decorations. Compared to macOS or something.
So you could say its design philosophy is inspired by macOS, but with many different ideas like that “Virtual Desktops or die”. But its basically macOS but less fancy, with a material-ish design like Android 13. I hate both hahaha.
KDE
Then there is KDE, which is really at the edge to look like the extremely outdated look of Windows 10 with these ugly rectangles everywhere, this no-round-corners fetish back in the day, “rectangles are elegant and good UI”. Such a completely weird step back in Style from Windows7, with less colors everywhere.
I have to say though, that Windows11, apart from a lot of stuff like their new design framework for Apps that wastes space, while also in part just already look really fancy, looks way better than KDE 5.
So KDE is now in the position to develop own ideas, but they pretty much go in the same direction as in windows, their new panel changer applet by Niccolo is veery similar to that, and it looks awesome! So I am certain the KDE6 will improve in Design a lot, even though I think I havent yet tried a KDE6 Plasma where projects like Dolphin where already ported to KDE6.
Projects like Dolphin are just great. I found it so strange and new back then to use a file manager with a name XD but funny, that Dolphin, Nemo and Thunar all come from the sea. Dolphin, Ocular, Spectacle, Ark, Kfind, KDE-Partitionmanager, Gwenview (something like Gimp but just for light editing, while still being in an unsafe language with security holes everywhere). These are all just great and unique software projects.
XFCE, MATE, Budgie, Cinnamon
Afaik these are all using GTK, so you could see them as outdated GNOME forks. Maybe thats very mean though, I see that Budgie will soon have Wayland, so I consider it an actively maintained Desktop.
I honestly can’t say much of the other environments, although I guess XFCE is based, had an okayish Design language that is at a solid base between Windows7 and some old Android.
Maybe if you tweak it it gets really modern, but I have looked enough Linux Scoop to know that every DE can look fancy with the amazing Community Designs. Actually Desktops should let random nontechnical Designers that dont understand Git make their Design. Like, no Code touching at all, just images please.
LXDE, LXQt, Window managers
Okay so these are basically energy saving DEs. They dont support lots of stuff simply, with their Design being at Windows XP or earlier. If you dont even have a menubar, that doesnt have to be styled.
So the Desktops maybe for old hardware and energy saving. If they have Wayland, so they can easily be used as the Window Manager of a Desktop, some Distro, Budgie or so, is looking to use an existent Windowmanager as their own. Just not with their own big Design Language, so they can make it “the Budgie Window Manager” without much problems.
I tried Fedora Sway and that was basically broken? My mouse was deduplicating and spamming the screen full with mouse symbols, meanwhile I could look at that… modern and colorful Titlebar, no Viridis or whatever actually thought through Color pallet of child crayon colors on a rectangle Bar with Terminal Font? Who wouldnt love this much “basedness”? But it broke, so yeah uninstalled that.
Cosmic, Hyprland
Now here come new projects, that actually have Designers working on them. Aaand in the Case of Cosmic it is entirely written in a damn safe language.
Okay its fair to say that Hyprland is a cool looking Window Manager, but Cosmic is doing something insane here.
Nearly all these bullshit old buggy File managers are in some C/C++ code, that just always breaks.
These are often 15 years old projects, they said “they cleaned up the packages” just by porting them to Qt6! Imagine what background changes they just left, because they would actually need to cleanup everything?
So Rust. Slint is said to be Qt-like, but not relying on C++, making it an incredible pain to write in Rust as you need to do some OOP translation that I dont understand because I am not in IT.
So Cosmic is doing something crazy and kinda new. Their interface was starting basically as a GNOME extension, quite literally. And there are many people layering just that package on their Fedora Silverblue (or future secureblue?)
But it is still basically imitating GNOME, with GTK support being one of the first GUI Framework integrations to come. They are doing nice material android-y things with their apps, and I imagine they are going in some direction here. Much like Android actually.
So COSMIC is a great beginning, but I think Rewriting something similar to Qt, with loots of frameworks and GUI Interface creation tools would be a statement. Like the Qt Creator, its crazy, a bit like this stupid TinkerCad but actually working and not being Windows-only and blocking Adblockers without even displaying Ads.
It would probably be “Qt stuff + Rust + Translation”, as the Qt people will likely not switch to Rust just like that. But having the core Apps, Kwin, the panel rewritten in Rust, that would be incredible.
Kwin is already working kinda well, but now there is the Cosmic Desktop with whatever WM and they could just reuse that and adapt it a bit.
So yeah, its a big deal for Interface Frameworks to rewrite all their stuff in another, extremely different language.
Here is an alternative Piped link(s):
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
I’m still waiting for them to be documented
Slint has fairly decent docs and has worked fairly well for my small projects
GTK is in bare
C, which is rather easy to interop withRust. 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.
Rust can use all basic C data types, but it can’t use C++ classes, in any straightforward way at least.
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.
As far as I can tell, C++ interop has come a long way. It’s not as bad as it used to be. Various projects seem to use Rust and Qt together now, without all of the
unsafe {}blocks that early attempts required.
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.
It’s worth stating that QT is an optional backend and is only used for native styling, even the pure rust, Native styling still looks close to native. QT is fully optional and is not a dep even for linux apps
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.
Qt with C++ is a spectacular environment to develop UI apps in. Coupled with QtQuick it’s even better. It’s perhaps only outclassed by Flutter. As others have mentioned, there’s lots of inertia behind GTK+. There’s also past issues with licensing which made the OSS community prefer GTK+ to Qt.
I’ve no idea what’s involved in using Qt in Rust but people starting new UI apps in C and GTK+ today are likely doing a disservice to themselves and the larger OSS community that could contribute to development and maintenance.
Gtk has had better rust bindings than Qt for a while. With modern tools (cxx interop stuff) Qt is actually quite usable. I believe Gyroflow uses Qt and Rust, for example.
Early wrappers for Qt tried to make Qt’s object ownership model fit with Rust, which led to a situation where every Qt call was unsafe. That’s not a very friendly way to write Rust, and kind of takes away the reason most people use Rust over C++ in the first place.
I expect more KDE devs to start using Rust in the future now that Qt bindings seem to be a solved problem, but like with other frameworks, it may take a couple of years for anything noteworthy to show up.
Don’t expect Dolphin to get rewritten in Rust soon, though. It uses a lot of C++ tricks to get plugins and such dynamically loaded and I don’t think Rust can accomplish that level of C++ interop quite yet. Where Gnome’s file browser is calling out to a lot of different daemons and subprocesses (which is slower but harder to crash on), KDE prefers performance over potential stability issues. Both are valid approaches, but I think Gnome’s approach makes it easier to port projects to other languages.
Interop with C was given first class support in Rust, so the Rust scene tends to tap into the C ecosystem more than C++'s.
No specific rust experience with either, but some thoughts on the popularity reasons outside of the language:
I suspect a bit part of this difference in framework popularity may be due to GTK being more attached to gnome and friends, and by extension, Ubuntu (for better or worse, the most used desktop distro for quite a while) Most of the time that’ll be mainline Ubuntu which has always been GTK.
So if a developer or company is going to target something, then it may come down to “what is the ideal platform to build on for Ubuntu as our main target? GTK? Cool, that’s what we will use.” Of course, either framework is just fine, and either framework targets other OSs as well. I don’t have any experience with either, but it wouldn’t surprise me if the choice of GTK more often is akin to Swift + Apple’s toolkits for iphone development being more popular by a large margin than Ionic/Capacitor, React Native, Xamarin, etc, even though the others provide some benefits (and some significant context-dependent downsides, of course)
If i remember correctly, Qt was not fully FOSS for a while, so GTK was much more widely adopted and recommended early on. But that was pre-2005, I think.
I generally don’t really think this is the case, there are still plenty of apps from other languages in QT. in fact, for cross platform apps, QT is immensely more popular then GTK is. Rust itself had disproportionately less apps developed in QT then other stuff, (Python for instance). especially when you consider cross platform. and at least for open source anyways. closed source I cant comment on
deleted by creator
