Experience with QT and GTK
Posted by Coammanderdata@reddit | linux | View on Reddit | 120 comments
Hello all! I am thinking about making a Linux desktop application, and am in the process of deciding which UI Framework I should use for it. My decision is coming down to QT and GTK. I have several questions for the community:
- Has somebody got experience with both of these frameworks and can tell me about pains and pitfalls associated with them?
- What front ends do you usually find more appealing, the ones developed in QT or using GTK?
- Are there some other ui libraries I should look into? (I am aware of electron, its absence from the question is by design)
Clear_Safe_5408@reddit
There just different, QT has very bad licencing terms, GTK is very permissive compared (LGPL), if you dont want to get sued for not exposing your code in GPL (QT) you can be sued. Otherwise you have to pay like 300+ dollars month, ( https://www.qt.io/pricing ). There is CopperSpice, which is a fork of QT 4 designed to be more optimised and streamlined. But QT has amazing docs and support. Plus a hotline for support—just depends on personal preference.
AppearanceHeavy6724@reddit
QT has sane fractional scaling, which is becoming the norm today. GTK is far behinf in that respect.
tristan957@reddit
From what I understand, GTK5 will improve this significantly since GTK4 is hindered by API compatibility. Stay tuned!
Phenee@reddit
is this a joke? gtk is the last framework on earth to care for backward compatibility and breaking things left and right with their major version updates. also, v4 hasn't been around very long.
AppearanceHeavy6724@reddit
but when?
tristan957@reddit
No timeline.
thp4@reddit
Both are fine.
Qt has QML going for it (nice declarative UI language, with JavaScript as glue/UI logic), and you want to write your "application" logic mostly in C++, although Python is also an option (PySide -- but it's not "pythonic" in the sense that the C++ heritage "bleeds out" in the APIs). Also, Qt is nice if you want to also build for macOS or Windows (either now or in the future), or if you want to build something that looks "at home" on KDE/Plasma.
Gtk+ is nice because its core is written in C and the GObject system maps nicely to many programming languages (GObject Introspection-based bindings), so most Gtk bindings you'll find feel very natural, and you can pick whatever language you want (e.g. GJS, Python, Rust, Go, Vala). Describing the UI in GtkBuilder/Glade isn't as nice as QML, though, and I haven't checked recently what the developments are there. If you want nice native integration with GNOME, Gtk with LibAdwaita is the way to go.
In the end, just like with programming languages, it doesn't matter which UI toolkit you use. Create a toy application in both of them to get a feel, then stick to one and spend time making your GUI nice and usable. Have fun!
domoincarn8@reddit
While I agree with you on the language front, I find that oft times its not the language, but the tooling around it that makes one better.
On Qt side, you have QtCreater, a very good IDE, with built in UI integration. Building an app with UI is a breeze in QT. Everything is integrated, right click button (or UI Element) and go to function to write code for that. Makes coding much much faster. Plus integrated debugger and valgrind integration means that issue solving and checking for memory leaks is extremely easy. And add to that VCS integration, its simple to use be it svn or git, or any other.
On the Gtk side, its a proper pain to design a UI and code it. The C side I can easily handle, its the rest that is a pain.
So, tooling matters a lot to me personally.
LibreTan@reddit
What is the application by the way? Will it ever be used on smaller screens like tablets?
Coammanderdata@reddit (OP)
No, it is purely meant as a desktop application
testicle123456@reddit
Your only good option when using qt is c++ really
Coammanderdata@reddit (OP)
I was maybe thinking about using the rust bindings, because it would be a nice learning experience, and I am a huuuuge fan of Rusts robustness during runtime. But I did not look into it that much
Zettinator@reddit
Rust bindings for Qt are no good unfortunately. If you want to use Rust, GTK is a much, much better choice.
mmstick@reddit
Or libcosmic
Coammanderdata@reddit (OP)
I guess that is a very unbiased suggestion XD I did not consider it however! I am gonna have a look, thanks!
mmstick@reddit
I'd recommend to start with this app template: https://github.com/edfloreshz/cosmic-app-template
Coammanderdata@reddit (OP)
Thanks!
Coammanderdata@reddit (OP)
Hm, from what I've heard QT is the way to go tho... Maybe it's gonna have to be C++ then
jask0000@reddit
If you already know Rust and would like to use it then I suggest to give a read to https://gtk-rs.org/gtk4-rs/stable/latest/book/ and see if it clicks for you.
jask0000@reddit
QT is more spread and so it also has more fans because it isn't so strongly coupled with single ecosystem. On the other hand It is strongly coupled with one or two languages it has first party support for. (Cpp and python)
GTK is gradually being visually tied to Gnome ecosystem. However if this is not problem for you (doesn't matter if you like gnome or just don't care how the UI looks), you can actually take advantage of GTK integration into other languages.
Both can have steep learning curve especially if you use them from their non-native languages. Because language support doesn't mean you don't have to deal with life-cycle/runtime of original implementation which tends to be different to used language standard. But both can be easy to use once you get over basics.
a_little_niche@reddit
The python bindings (pyside) are good - I've used them a lot.
ProjectInfinity@reddit
The go bindings look pretty OK to me.
gen2brain@reddit
Which one, they are all dead and unmaintained?
tajetaje@reddit
You can use QML for a lot of stuff though
testicle123456@reddit
Yeah but you need to implement the logic in c++
tajetaje@reddit
True, but Qt-style C++ is a lot simpler than normal std C++. You do still have to do a bit of memory management but Qt handles a lot of it and you rarely need any libs besides Qt ones
Zettinator@reddit
The downside is that Qt almost completely sidesteps the C++ standard library and the improvements new C++ versions brought to the language and standard library. Interoperation between "QC++" and code that uses standard C++ containers, and many external libraries for that matter, is quite cumbersome. If you are used to modern C++, it actually feels like travelling back in time.
the91fwy@reddit
The Q classes now in libstdc++ exist from before they were stdlib functions. They actually use the stdlib implementation internally when available and you can transfer types with ease.
testicle123456@reddit
Oh yeah, this is definitely true. QT C++ is so much less tedious.
Zettinator@reddit
Please don't. QML/Qt Quick is still pretty bad for desktop applications. You can't really mix classic widgets and QML well either.
gmes78@reddit
A lot (most?) of KDE is written in Qt Quick.
tajetaje@reddit
Depends on your app/use case IMO. Pick the tool for the job.
Zettinator@reddit
Well, they've tried to push QQC 2.x as a full replacement for Widgets. It isn't... not even close.
Mo_Jack@reddit
Has anybody heard of FerenOS? It runs on Plasma but is making an environment to run both GTK and Qt.
From its website:
I remember running one DE (KDE or Gnome) and when I wanted to play games from the other I had to download a lot of the other DEs files. Many of the games worked but I also remember having some conflicts. This was probably 10 years ago.
MetaTrombonist@reddit
As nice as Qt may be for developers, it still seems pretty buggy on Wayland (a good example of keepassxc, which still has issues with menus and window placement). As an end user, I generally prefer using GTK apps instead of Qt ones whenever possible.
tristan957@reddit
Aps running on Wayland cannot place windows, so this is probably just a Wayland limitation.
TiZ_EX1@reddit
If you want to target Windows and Mac as well, you're best off with Qt. I don't think that using Kirigami on top forces it into a Plasma-specific HIG the way Adwaita does for GNOME, but I am not remotely sure about that. If you are making an app primarily for Linux, but you want it to fit in okay in every DE, you want GTK 3, or GTK 4 without Libadwaita. If you want to make an app primarily for GNOME, or you want to be sure that users can't mess with it very much, use Libadwaita. It should be noted that GTK's breadth of programming language support is second-to-none. I don't know how true that is for Libadwaita.
tajetaje@reddit
Yeah Kirigami is cross platform. That’s why apps like Kate and Konsole work on windows
clau_c@reddit
Neither of these are Kirigami apps
tajetaje@reddit
🤦♂️ well those aside, I do recall Kirigami stuff working just fine on windows
1stRandomGuy@reddit
Elisa, iirc, is a kirigami app
daemonpenguin@reddit
Qt, definitely. It's more modular, better documentation, better cross-platform support, less breakage between versions. GTK is really only a good choice if you're making a GNOME-specific application or can't use C++/Python for some reason and need to use C.
TiZ_EX1@reddit
I disagree with the assertion that GTK is only a good choice for GNOME-specific applications. Libadwaita is only a good choice for GNOME-specific applications. GTK by itself does alright in pretty much every Linux environment.
reddithorker@reddit
There are GTK applications written in Python. Deluge and Lollypop come to mind. Otherwise I agree.
Ran_Cossack@reddit
All you need to do is read the vala documentation and try to guess how/if they implemented the parts you need in Python, easy-peasy import gi, gi.require_version("Gtk", "3.2"), gi.require_version("Gdk, "3.2"), from gi.repository import --
Anyhow, eventually it can work, with enough trial, error, and consulting existing projects.
...
Or you can just read the documentation at doc.qt.io.
jask0000@reddit
There is full PyGObject reference available https://lazka.github.io/pgi-docs/
For more than reference guide read C docs not Vala docs.
purpleidea@reddit
I know everyone here is saying QT, but GTK really is a good looking, elegant platform. One of the reasons the GNOME desktop is more popular than KDE. Both are great, but it's true in the proprietary space, QT is more popular.
PorgDotOrg@reddit
This isn't a comment on the quality of GNOME vs KDE, but I think it's hard to ignore the power of defaults at play here. GNOME has been the default on a lot of distros for quite awhile. Defaults are a powerful influence on user behavior, and I hardly think the difference in desktop share represents a difference in quality here.
KnowZeroX@reddit
A lot of that had to do with the early days licensing issues of QT. And even after the licensing issues got sorted out, there was the stigma it created. And as many distros made Gnome the default, it solidified. If not for that, who knows KDE may have become the most popular desktop
jask0000@reddit
Both are ok. Especially in the past Qt seemed to be more mature and developer friendly. But especially in GTK4 it improved a lot too. Small issue of GTK can be seemingly fragmented documentation that can be a bit confusing from the start but overall it has a good quality. And there is a big community to help with that anyway.
Unless you already have some strong preference I would recommend to base your decision on two points.
jlpcsl@reddit
I used both and most definitely would go with Qt. It is much nicer and more intuitive to work with, has much better documentation, much better cross platform support also has more features available to use. Also I find tooling around it to be better (e.g. Qt Creator IDE and Qt Studio and such). For me Qt is the best GUI toolkit I have worked with and I would say it leads by quite a large margin.
ArrayBolt3@reddit
I also would recommend Qt. I've tried using GTK in a number of different forms and it was always just... clunky. Apps built with GTK are oftentimes really good, but the actual "guts" of GTK are just not as easy to work with as Qt in my experience. This especially becomes a pain point when you want to design UI files - you have to write them by hand in XML, or you have to write them by hand using a layer over XML called Blueprint which is still somewhat painful to use. Plus if you want to use GTK, you usually have to use either C, Vala (a special language specifically for making GTK apps), or use some binding that connects your language of choice to GTK. Qt on the other hand is C++-focused (and C++ is easier than C in my opinion), and there are native Python bindings via PySide.
jack123451@reddit
C++ is a much more complicated language than C, but it's biggest strength for this particular use case is that the language -- hence the compiler -- has first-class support for OOP whereas OOP is bolted onto C using GObject and a bunch of macros.
zaytzev@reddit
I concur. Fortunately for Qt apps you need a relatively small subset of C++ so it might seem easier.
vitimiti@reddit
C++ is complicated until you realise you don't have to remember to prevent memory leaks everywhere. It is a higher level language if you use the Qr and standard libraries, it is horrifying if you use C with classes
Business_Reindeer910@reddit
too bad the lack of acceptable bindings to other languages makes it too difficult to choose.
gmes78@reddit
The Python bindings are amazing.
Business_Reindeer910@reddit
i'm sure they are, but that's only one language
MeanEYE@reddit
I didn't touch Qt in a while. It's okay but I honestly don't like its widgets and their design philosophy. GTK+ is my preferred toolkit for making desktop applications. Partially because of GObject Introspection, which allows you to use GTK from any language you want. This is important when you have to mash something up really fast so you naturally reach for whatever you are most comfortable with. Another reason why I use GTK is because I use Gnome desktop so tools I make fit nicely.
Personally I prefer design of GTK3+ applications where focus is on simplicity while advanced options are hidden in the menus but available. Qt applications, or at least ones made by KDE developers, tend to be configuration heavy. But this is just a personal preference. Both frameworks are good and do what they need to do.
Choice of other than these two, depends on language you are going to use. Also I'd avoid Electron like plague. Idea of bundling a browser and writing your user interface in CSS because learning how to use native library is just not acceptable to me. I've seen note taking applications which take 300MB of RAM because they were on electron, not to mention battery consumption on mobile devices, lacking accessbility tools support, etc.
DottoDev@reddit
Taurin would also be an option, at least it's better then Electron
MeanEYE@reddit
Much better approach although it still eats a bit much memory. At least we don't end up with dozens of browsers installed.
ProjectInfinity@reddit
Tauri doesn't "install a browser", it uses the system webview which already is installed. My relatively simple application that I wrote to just test Tauri used a whopping 44.7MB of RAM and was a installer for STALKER GAMMA on Linux. https://imgur.com/a/uxgoDMZ
MeanEYE@reddit
I know I looked up Tauri once mentioned. I was referring to Electron and said it's a benefit we don't have many browsers installed with Tauri applications.
ProjectInfinity@reddit
Then I'm not sure where your ram claim is coming from since it's very ram efficient in my testing.
gen2brain@reddit
But, 50M is a lot for a simple app, It is like, 10x more than it should use. And I guess that is in ideal conditions, i.e. I don't even have webkit2gtk installed, and nothing is using it, it would be much higher for me, right?
There is a nice memory footprint of toolkits here https://szibele.com/memory-footprint-of-gui-toolkits/ .
ProjectInfinity@reddit
50MB for an installer is not a lot. 50MB in general is not a lot.
gen2brain@reddit
I thought 50M was RAM usage. I don't care about the size of the app on disk, but app memory usage is a very important metric. Even for RAM, 50M is not a lot depending on what the app is doing, but for a window and few buttons that is huge, and I remember the electron hello world app eats like 200M.
ProjectInfinity@reddit
It's not a hello-world application. I could do that in 2MB or less in Tauri. It's an actual installer, it downloads multiple GBs, unzips in multiple locations etc.
MeanEYE@reddit
I just saw video by Fireship and in it he compares memory usages, showing 100+ for Tauri. Can't say I've used the tool myself.
Zettinator@reddit
Since shared libraries are, well, shared, it's very hard to say how much memory an application actually needs. If there are already some instances of the system webview running, it's going to by low. If not, and that could actually be the case depending on what the "system webview" actually is, it's not going to be that low (unless you're running multiple Tauri apps at the same time or the like).
Zettinator@reddit
You get smaller executables and less resource usage in exchange for a lack of consistency and compatibility, since browser engines can vary a lot.
ProjectInfinity@reddit
GTK doesn't do a good job at cross platform. Qt does.
blackcain@reddit
It's much improved - lot of work on the windows and macos implementations. It's not well advertised though.
MeanEYE@reddit
This is something I'll have to check although I did stop supporting other systems, it might be good to have that option. Any further resources you'd like to point out?
blackcain@reddit
Look at Christian Hergert's blog - he's been doing a lot of work on the MacOS port of GTK.
https://blogs.gnome.org/chergert/2020/12/15/gtk-4-got-a-new-macos-backend-now-with-opengl/
GTK4 is really a huge leap forward. Extremely scalable widgets now. That's why nautilus is now going to be the new filechooser, and why it can support tens of thousands of files. Just really amazing engineering work.
QT is great - but GTK is truly a community driven effort and what about 100 volunteers can do to maintain this codease is pretty amazing.
MeanEYE@reddit
Oooh. I'll have to look into that. I had to jump through some serious hoops to make Sunflower be able to list huge directories with 10k+ files in them and have at least somewhat decent performance.
blackcain@reddit
Please ask on discourse.gnome.org
But here is the relevant blog from mclasen about it: https://blog.gtk.org/2020/06/07/scalable-lists-in-gtk-4/
MeanEYE@reddit
Thanks!
MeanEYE@reddit
To some this is benefit to others not so much. It really depends on what developer is set to achieve.
If cross-platform is goal, then great. But that means you have jack of all trades and master of none. Widgets have to conform to all the systems after all.
On the other hand GTK has become very Linux specific, even though Gimp for example still uses GTK on other systems. But being very specific to a certain OS or even desktop environemnt means application can integrate deep and seemlessly.
ProjectInfinity@reddit
Should also be mentioned that while gimp is gtk on all platforms it is gtk2 which is much less tied to gnome and Linux than 3-4 is.
MeanEYE@reddit
They are planning a switch to GTK3 for 3.0.
blackcain@reddit
Once the release happens for gimp 3 - I expect the gtk4 port to move quickly.
MeanEYE@reddit
I think so too. From what I've gathered it's a much easier transition. Some widgets got deprecated, libhandy was added but nothing too serious.
blackcain@reddit
libhandy is no longer a thing - libadwaita is king. I think the split (or hte re-split since htis is the 2nd time we are doing this :-) of GNOME apps from GTK is pretty cool.
MeanEYE@reddit
That's the one I meant. Keep mixing the two. You say split from GTK, wasn't libadwaita just suppose to be kind of abstraction for smaller screens and mobile devices?
Lord_Zane@reddit
It's both. libadwaita provides some "adaptive" widgets that work for both normal desktop window sizes and mobile/small window sizes. That's one goal of the library. The other is providing widgets and styling implementing gnome's design system, which is what makes a gnome app look like a "gnome app".
The idea being that GTK can focus only on being a general GUI library now, without inbuilt styling or widgets for gnome's use case, instead of having the dual role of a general purpose widget library, and gnome's platform.
LvS@reddit
The main changes in GTK4 are internals. Applications are easiest to adapt, custom widgets are somewhat more complicated, but the hardest part by far are things that integrate with internals.
For example, GTK4 renders entirely with the GPU, so if your GTK3 code does lot of rendering tricks with Cairo, you can basically rewrite that.
GTK4 also has an entirely new clipboard/dnd implementation, so if you had fancy hacks with GTK selections in place, you gotta redo them, too.
I don't know how involved this is for Gimp, as it is an old codebase with lots of accumulated ~~cruft~~ features. But it doesn't really need anything special from the toolkit, as it's the typical content area + lots of tool widgetry around it, and that's usually fairly well separated.
Coammanderdata@reddit (OP)
The language doesn’t really matter that much (as long as it’s not JavaScript) But I would prefer C++ to C for example
MeanEYE@reddit
Qt doesn't have C bindings, you can do Python or C++. Maybe some other language am not familiar with. GTK+ it's up to you both C and C++ is available, as well as Vala.
x1-unix@reddit
Flutter and React Native are also descent options too as they offer declarative way to write UI logic (like SwiftUI).
lanavishnu@reddit
Back in the day of python 2 I made a framework for gtk apps. So every type of widget had a function call and every widget had a dictionary you would use to create it. I'd lay out rows of widgets, and then had functions to initialize and run the application. All the widgets had call back functions as part of the dictionary and that was how you defined the functionality of the application. So, one application was a phone dialer for my Android phone with a contact database.
The reason I needed the framework was that gtk is kind of a mess unless you do it that way.
More recently, I've switched to using QT Creator for C++ apps. It's cool, but a bit involved. Of course it's hard to compare because one was written in Python and now I'm using c++, which makes things kind apple's and oranges.
ObjectiveJellyfish36@reddit
I'd go with Qt since it has much better cross-platform support.
Zettinator@reddit
But does it matter? It doesn't look like OP actually wants to build a cross-platform application.
ObjectiveJellyfish36@reddit
Sure, OP didn't specify the scope of his app, but I don't think it's smart to deliberately limit your app's scope to a niche operating system, when you can easily target other OSes with much more users, and in the process get more contributors too.
vitimiti@reddit
I have used both and GTK is a bit of a pain imho, I'd go with Qt/KDE. But at the end of the day you need to look at your needs and at what you want to sacrifice and choose what better suits your plans/needs
Apprehensive_Bit464@reddit
Qt is for boys, GTK is for men
manobataibuvodu@reddit
I haven't used any framework to make an app myself so I can't comment on that, but gtk/libadwaita apps are so much prettier than qt it's like in a whole different league. GNOME designers did great work on the HIG.
Monsieur_Moneybags@reddit
Between Qt and GTK I'd pick Qt, for all the reasons everyone else mentioned. Besides Qt, some other C++-based toolkits are wxWidgets, FLTK, and FOX. Besides GTK, Motif is the only other major C-based toolkit I know of (some older ones seemed to have died off).
S48GS@reddit
You have Electron - javascript snd css is better than anything else - you will just integrate exist web frameworks and everything will work.
Today is 2024, not 2005 - use Electron.
testicle123456@reddit
Nah, I like having my stuff well integrated into the system and not installing and running 20 instances of a whole web engine at the same time
S48GS@reddit
Sound like you have never ever made even singe app, actually useful app even if just for you but you know that is useful.
In reality - you have multiple devices with different architecture each and different OS - and web-app will work on every single one of it with minimum effort and without downloading 40Gb dev-environment for each.
ericek111@reddit
And kids, this is why the JetBrains Toolbox, a single systray icon with one basic pop-up list, takes half a gig of RAM.
S48GS@reddit
Every smartphone have 8Gb minimum ram.
50%+ PC with 16Gb minimum.
again its 2024
ericek111@reddit
8 Gb is 1 GB, so I'd agree.
If I had 16 GB of RAM (8 is still the standard for lower-end machines, including, for example, the $2000 model of MacBook Pro), having eight memory-hungry apps made by lazy devs would mean the difference between being able to afford to run a VM without closing my work.
Again, it's a waste of memory that could better be utilized elsewhere.
testicle123456@reddit
I only write stuff for Linux - specifically kde. I try to avoid Electron apps if possible but I understand their value. Using them for everything is really stupid though. QT already does multiplatform very well
ProjectInfinity@reddit
Unironically you are correct in that HTML and CSS gives unprecedented amounts of freedom to create what you want, not everything needs to be an electron app however.
tgirldarkholme@reddit
Nobody cares what a front-end web "developer" thinks.
apollo-ftw1@reddit
I tried making a gtk kindle app once, didn't go well
Just go with qt, it's better imo
Faranta@reddit
I think you might want to look at .NET / Avalonia as an option too. Allows you to use a modern framework and languages, which might be more enjoyable than GTK framework or C++ language for QT. Ubuntu includes .NET as part of the default installation now.
Plus I think Avalonia also runs on Windows, Mac, and mobile pretty easily.
What really bugs me is that choosing between KDE and Gnome means the styling of the applications of the other desktop environment is usually broken, especially with Flatpak. I wish there was one universal theme manager for both KDE and Gnome that would allow you to set GTK and QT themes.
LvS@reddit
The styling is also broken if you fix the drawing. It will even be broken if you make the paddings kinda match.
Because KDE and Gnome have different human interface guidelines and generally different ideas about how to layout widgets in an application. I believe there's also mismatch with various keybindings.
It's been the same with mobile - at the beginning people tried to write apps that looked native on Android and Apple and it just didn't work. You ended up with an app that felt native on an iphone or an Android phone but never both. Worse: often it felt native on neither.
That's why developers decided that it's much better to be different than trying to be the same and failing at it.
Business_Reindeer910@reddit
some folks alluded to this, but didn't say it explicitly.
Your programming language of choice would really factor in here. Qt's bindings for things not python and C++ are pretty not great.
Murky_Onion8109@reddit
Qt
agoldencircle@reddit
Sure, but this is my experience from 10 years ago. Feel free to correct me.
Creating lots of widgets in a short time is a huge pain in GTK. There's GLADE, but integrating it is a bit painful. So ui gets constructed manually. It's also very verbose. Also you're limited by the type of callbacks and the fact that it's trying to do OOP in C. Some API design decisions were just dumb. I found it impossible to add a context parameter to a callback. Documentation is also dated. Though perhaps things have changed in this regard since then.
Source: I was going to make a media player frontend to mpv in gtk around 10 years ago but hit a few roadblocks. I was going to call it simple player. At the time gtk was my favorite toolkit.
blackcain@reddit
The tooling for libadwaita/gtk apps have greatly improved - check out these apps: https://github.com/workbenchdev/Workbench https://flathub.org/apps/ar.xjuan.Cambalache
It's a lot easier to do design and then with GNOME Builder you can easily create a flatpak using whatever language.
MeanEYE@reddit
Situation with GLADE has improved significantly. From GTK3 you have Gtk.Builder class to which you just pass the XML file and you are done with it. When you want to get a component from the interface all you have to do is call
get_object('name').Passing data to callbacks is also eays and has been since GTK2 days. At least with Python. You'd call
object.connect('signal name', handler, extra_data). Then that data is passed when event handler is called.Documentation these days is automatically generated since introduction of GObject Introspection.
My applications mostly rely on manual building the interface but only becuase they are really old at this point and I don't feel like recreating everything and introducing new bugs.
blackcain@reddit
For those looking to write a desktop application - please register and attend Linux App Summit (https://linuxappsummit.org) - both GNOME and KDE are hosting this jointly - meet the developers, designers and what not. Get the latest on what's going on. :)
BrageFuglseth@reddit
Are you enjoying the environment you’re using right now? If so, it’s probably a good idea to choose its platform technologies (QT+Kirigami for KDE, GTK+libadwaita for GNOME, or GTK+libxapp for Cinnamon/XFCE/MATE). This requires that you have experience with the needed language(s) for the given stack, but other than that you’ll already have some knowledge of the design conventions used by that environment, which is a big advantage.
Coammanderdata@reddit (OP)
I am not using a de😁 But thanks for the input
PineconeNut@reddit
I've only used QT and it's not bad. I went for QT because it's what KDE uses and I'm a KDE guy.
I would recommend QTcreator dev environment if that's what you go for.
JRepin@reddit
Another strong recommendation for QT. Others already said why. There is a lot to learn to take full adventage of everything and it is well wort the time. Real pleasure to work with it.