I love KDE,I like QT, why is GTK the preferred toolkit on Linuxes these days ?
I would really like to see an objective analysis, I am not in the camp of KDE/QT against Gnome/GTK, but in modern times, what makes GTK a better goto choice in respect to other frameworks(QT, FOX, FLTK)?
Is it inertia, is it philosophy, is it technical details, is it licensing policy ?
Just a thought: maybe KDE is the reason why GTK is so popular.
I've been a Linux user for roughly 14 years, and every time I try KDE, I can't seem to give it more than 5 minutes. The KDE UX is like kryptonite to me. I feel like a senile old lady when I use it, unable to grasp what the hell is going on.
I briefly tried KDE again when GNOME 2 was killed, and I uncomfortably went back to GNOME. I deeply disliked GNOME 3, but at least I found it usable. (I eventually switched to XFCE).
I know KDE is a mature, large, beautiful project, but ultimately a desktop environment is about user experience, and KDE's doesn't click with me. I'm aware my experience is entirely subjective, but I suspect there are others like me who just can't get used to the K. So we end up in GNOME, and by inertia resort to using and developing GTK applications.
I think it'd be very cool if there was something like XFCE for Qt. Maybe LXQt will play this role in the future.
KDE's major sin is the lack of a sane, usable, default configuration.
It took me a few years to understand that people don't want to invest,
not even a few hours, to configure their DE. And KDE comes with a lot
of configuration settings. So they ended up in Gnome.
I've been using it for ~10 years and although it's the only DE I can
get any job done, even today the defaults are ugly and overwhelming.
And only a few distros(OpenSUSE only?) make an effort to provide a decent
KDE experience for the user.
In my experience, trying to use KDE is always a waste of a _lot_ more than a few hours. And even once I've got it configured the way you like, it feels like it's barely holding together with duct-tape at the seams. There's always a few things missing, always something, but I'm afraid to touch it for fear it'll all rip apart.
KDE feels like a mish-mash of disparate parts that sort of go together. Much of the "work" I do in setting up KDE is giving it a clean and consistent interface.
So I, too, always go back to GNOME after trying KDE for a few weeks.
I think Linux users in particular don't mind investing in their DEs, but the investiment cost shouldn't be so high in the beginning as to scare off new users. DEs have to carefully balance a good initial configuration with the flexibility for long term usage.
A second issue with "investing in your DE" is that we tend to update computers and installations a lot these days. Any extra step required to configure your environment becomes tedious over time. I used to have a rich dotfiles folder, but the pain of maintaining it became so high that I slimmed it down to the absolute minimum. I even forced myself to conform to some programs' defaults. The less time I spend hunting for this kind of highly specific documentation, the better.
It's just that it saddens me that the KDE people don't seem to understand
that first impressions are a big thing. I really believe that in terms of
engineering KDE has no competitor... on any platform or OS. But as history has
shown us, this is not enough. When an avid KDE user like me can't stand
the defaults and spends 1-2 hours on every new installation to make it
usable, something is not right.
Also add to the fact that at some point I need to get some work done and
not mess with DE config options... sigh.
Before I started to use Qt in my python projects, I was using GTK. At the time, there was no absolute reason for doing so - it was merely the first thing I tried.
For various reasons (memory is vague, it was a while back), I soon began to get frustrated with GTK.
Then I started reading various articles on the subject of 3rd-party Gnome theme designers getting extremely frustrated because for every point release of Gnome/Gtk, their themes broke in lots of annoying ways. I read about those frustrations, about incredulity that a point release introduced non-backwards compatible changes, about anger at Gnome developer's responses to those frustrations.
Gnome itself.. I stopped using Gnome desktop not long after that - the big push for me was the transition from being a great desktop environment in Gnome 2, to some horrible abomination in Gnome 3. Now, some people like Gnome 3's way of doing things, I don't. For similar reasons I refuse to have anything to do with Ubuntu's Unity.
The Gnome developer response to issues leaves something to be desired... "We know best, shut up!" is the best way I can describe my impression of them. There's something almost, dare I say it, Communist Party in my opinion, of how they do things. It puts me off.
I've been using KDE since then - it presents me with a desktop that's useful to me.
It also led me to try out the Qt library. What a breath of fresh air! Well documented! No unexpected changes in operation or backwards-incompatibility in minor revisions! Great responses from Qt/KDE developers!
Anyway that's my own personal experience - I wouldn't dare suggest that is why others choose Qt & KDE in favour of Gnome/Gtk.
I can't speak to the developer experience for Qt vs. GTK, but one day the scrollbars in the GTK-based programs I use started going into ultra slow motion if I held down the mouse button for 1/4 second.
While looking for a place to report the bug, I discovered this is an intentional "zoom" feature. Almost nobody knew about this amazing(?) feature, so with virtually no discussion, it was made to activate automatically to be more "discoverable".
Personally, my life would be better if I hadn't discovered this UX regres-(cough)-feature. This sort of thing also reflects poorly on the software using the library. (Initially I thought Synaptic was broken.)
I'm surprised that a mature library can change overnight in such a far-reaching way on some dude's whim.
Theming was completely redone in the last years in GTK+3, that's why a lot of themes broke... it is now all done with CSS, and the 2 previous GTK+ specific theming mechanisms are deprecated.
Which means that you can now at least point the developers to the W3C specs if you want to argue that something is a bug, and not something that only worked "by chance".
> There's something almost, dare I say it, Communist Party in my opinion, of how they do things. It puts me off.
Well, don't say it then. Putting GTK's first world problems on the same level as North Korea's atrocious regime is a poor way to qualify the Gnome developers.
That said, I share your opinions on the situation and love QT which feels much slicker to the end user and easier to code. And some of the Gnome dev attitude sucks, that's a given.
> Well, don't say it then. Putting GTK's first world problems on the same level as North Korea's atrocious regime is a poor way to qualify the Gnome developers.
I said it because it was the best way with the least amount of verbiage I could use to describe how their top-down, dictatorship-like, inability or unwillingness to listen, it's our way or nothing, you're insane if you think this is a good idea, feels to me.
I wasn't for one second trying to trivialise North Korea's problems - in fact I was thinking more about the Soviet-era - and I find it odd that you connected the two, and found the time to pick out that one sentence and make an issue out of it :)
> I wasn't for one second trying to trivialise North Korea's problems - in fact I was thinking more about the Soviet-era - and I find it odd that you connected the two, and found the time to pick out that one sentence and make an issue out of it :)
Ha, that's interesting because I actually first picked up USSR but since the soviet era is over I chose to go with NK for dramatic effect.
Recently the elections gave us a full liberal right political landscape in my home country and everyone is bashing the previous leftist and green parties with derogatory terms such as stalinism, gulag, dictators, etc. so the lexical field has been making me go on my high horses for the last few weeks because frankly it's not comparable. I'd rather label thing as they are when comparisons are too far fetched.
> Putting GTK's first world problems on the same level as North Korea's atrocious regime is a poor way to qualify the Gnome developers.
Woah, slow down there. The way I read it is just saying that all decisions are made by a central cabal and handed down without listening to the people.
North Korea's not the only communists out there, y'know. :)
I realize now that what I know of the NK political system is really naive.
> In 1972, Juche replaced Marxism–Leninism in the revised North Korean constitution as the official state ideology, this being a response to the Sino-Soviet split. Juche was nonetheless defined as a creative application of Marxism-Leninism. Kim Il-sung also explained that Juche was not original to North Korea and that in formulating it he only laid stress on a programmatic orientation that is inherent to all Marxist-Leninist states.
> Former North Korean leader Kim Jong-il officially authored the definitive statement on Juche in a 1982 document titled On the Juche Idea. After the 1991 collapse of the Soviet Union, North Korea’s greatest economic benefactor, all reference to Marxism-Leninism was dropped in the revised 1998 constitution. Kim Jong-Il incorporated the Songun (army-first) policy into Juche in 1996.
I think one of the main points is the language. GTK is a C framework, Qt is C++. A lot of people in Linux community prefer to use old school C. Also licensing was certainly an issue at some point. The open source project I was working on made the choice to use GTK because it was Free. If we had to make the choice now, again, we would choose Qt. But it is too late to rewrite years worth of code.
Also, while GTK is written in C, it is designed with cross-language compatability in mind. GTK has first class support in C, C++, Vala, Python, and Javascript (there are still more official bindings and countless unofficial bindings). Qt is almost exclusively a C++ framework. There are Python bindings, but they aren't comparable to GTK's.
It's a real problem. I really like to use QT, but I found that is problematic if you aren't using C++. For example on C, D or Java. There is bindigns, but or are lagging behind the last version of QT (ie Qt 4.8 or more older) with very few support or are abandoned some time ago.
To be honest, I don't care what language Qt is written. As long as there is a binding for my language of choice, as long as Qt does what the documentation says it does, as long as the developers seem to know their stuff, and listen to people's problems with agency, then that's good enough for me.
I'm not so sure if most of the people want to use GTK because it's C. Because usually that means that they have to deal with GObject which is not so nice.
Ubuntu is switching to Qt for Ubuntu Touch. If I remember correctly it is about building resolution independent applications, which GTK has (had?) poor support for.
For Desktop you can build Qt QML-applications with Unity/GTK themeing I think.
Really? I know that GNOME 3 (and maybe also Unity) are the DEs of choice for HiDPI displays, so I'd be surprised if there were any real deficiencies in GTK's resolution handling.
"GTK+ does not support resolution independence, Modern mobile devices have ultra high pixel densities. If you run a GTK+ application on a mobile screen all the user interface elements would be so small as to be unusable.
This has been an open bug on GTK+ since 2008 but they have not done anything about it."
Read the entire answer. I am no expert to validate if it is correct or not.
In my opinion, it might be related to Qt being a huge framework and ecosystem where GTK is "just" a GUI toolkit.
I don't know if things have changed recently but at Qt at least used to require custom C++ extensions. This requires you to use custom toolchains or the recommended way of using the Qt Creator IDE. This isn't necessarily bad (I've only quickly tried it out, I don't really know) but it certainly makes me look at other alternatives first.
This isn't perhaps a big problem if you use other languages than C++ and there are decent wrappers available. But having to use a custom compiler/preprocessor just to get a GUI up isn't what I really want.
Qt is a pretty intrusive framework and ecosystem, where you have QStrings and QSockets and QEverything. GTK is perhaps a bit more lean and mean library than a full ecosystem.
I've also noticed that Qt applications do not work very well over remote X connection over slow networks. Apps built with other GUI toolkits work much more fluently. (I understand that this is not very common these days but I still do work on remote X on a daily basis).
I am sure that the Qt frameworks solve practical problems in cross platform development, but I'd rather not get involved in a whole ecosystem when all I need is a GUI toolkit.
"Custom toolchains" is massively overstating things. The only mandatory thing is the MOC, which is just a preprocessor that spits out some more C++ code for your regular compiler to build, and it's easily integrated with ordinary Makefiles (or whatever other half-sane build process you want). qmake is optional.
(And I don't know what to make of your comment about remote X. Years ago I sometimes ran entire remote KDE sessions in Xnest and didn't really have any problems, so this would seem like either something new, or a problem with your environment.)
As another poster replied, remote desktop users are a lot more common than you might realise :)
I haven't found this problem with Qt and remote connections. Then again I usually use Xrdp with the X11rdp back-end. If you haven't already done so, perhaps you should try it, it works beautifully, and if you run a Debian-based distro, I've even written a utility which compiles X11rdp/xrdp and packages it for your convenience ;)
A lot of this is historical. So some thoughts in no particular order:
Back a decade ago qt wasn't cross platform, gtk was. So when I was on windows I was using pidgin (nee gaim), gimp, scite, Firefox... When I moved to Linux I of course kept using the same.
And back then to do cross platform what you usually did was use a meta toolkit like wxwidgets, which on Linux wrapped gtk. So again that was the cross platform toolkit.
Being in c meant complete bindings for a lot more languages especially with SWIG anything that didn't have the level of support of say python went with gtk bindings.
Until KDE4 qt brought with it a dependency on the entire KDE environment kedit, Kate, kstars, ktypingtutor, a bazillion things. Which always seemed like a lot when you just wanted a PDF viewer or something.
Because of the kparts architecture and just culture in general qt/KDE apps tended to include the kitchen sink Konquerer was the most notorious, but a lot of apps were like that, which felt very fat to a lot of people and not 'unixy' enough.
From what I've heard, GTK was born due to licensing restrictions of the older versions of Qt - Qt used to be dual-licensed, available either under a commercial license, or under GPL (not LGPL). Some people found that too restrictive.
No. Some people (especially the FSF) objected initially to the FreeQt license (which did not meet OSI and FSF definitions) and then the QPL[0] for a few reasons, most importantly because it was not GPL-compatible.
Qt/X11's release under the GPL came quite a bit later after GTK+ and GNOME were well on their way to becoming established projects.
I guess initially Gtk was preferred because of the licensing confusion around Qt while Gtk was clearly GNU open-source. Maybe Firefox for Linux would be based on Qt if it were started today; it would probably help for mobile. I doubt anybody would really be interested in moving an old code base like LibreOffice or Firefox over to Qt, so since they started out with Gtk, they will most likely stay with Gtk.
The last years – since Gnome 2.0 I guess, but definitely Gnome 3.0 – Gtk and Gnome have had an enterprise cleaning broom going through it, which has made them feel more restricted but also more uniform and less as if a bunch of hobbyists have each added their own pet project and preferences to a common code base.
I personally think Qt is great, and with a stronger corporate backer or design team KDE could be polished a bit better without taking away what makes it KDE. Gnome probably has a lot more corporate backing (for desktop) and paid developers than KDE, and I guess consistency and polishing of rough edges are helped by corporate backing and paid development work.
Qt is doing well on mobile though (Sailfish, Ubuntu mobile). It'll be interesting to see how this will influence the desktop side of things.
(For what it's worth – I have both Gnome and KDE installed, and use KDE most of the time.)
Regarding Firefox and Qt vs Gtk ... this is going back a long long time (to the Seamonkey days and prior to some really huge changes), but Gtk people were involved with Mozilla early on and as Mozilla contributors. Perhaps pavlov will step in and say something, but people like him, Chris Blizzard and others really stepped up early on. On the Qt side, there were some initial hacks to get the old codebase working with Qt from some Trolltech folks, but I remember that being something they sort of tossed over the wall ... and that was before the original Mozilla codebase was scrapped and the change to XUL happened.
Did KHTML exist back then and was it good enough that it deterred more KDE / Qt folks from working on Mozilla? I don't recall as it has been ages. Of course, KHTML went on to become the foundation of WebKit ... so much history!
I would choose Qt myself, but that's because I prefer writing in C++. Linux land is typically the C Fortress, is it not?
(Vala is making inroads in GNOME land though I think?)
I wrote Qt stuff years ago and found it well documented. I didn't even know where to start in GTK land. I have since moved to wxWidgets as it appears to be free of politics and fits in nicely under Mac OSX (some Qt stuff was obviously Qt under OSX I noticed)
> what makes GTK a better goto choice in respect to other frameworks (QT, FOX, FLTK).
I do not have an answer but I would like to show a different angle to this question: why do Qt applications often feel overly complex and GTK applications are usually much simpler to use?
In your examples, you are comparing KDE apps with GNOME apps. Though the KDE ones are all Qt and the GNOME ones are all GTK, it's not really a fair comparison since GNOME and KDE have different design objectives (KDE strives to be more feature-complete and configurable while GNOME wants to be simple to use and have a clean UI). The design choices in your comparison aren't dictated by the toolkit, but rather the HIG of each desktop. There are a lot of clean and simple Qt apps, like the official implementation of Tox [0].
VLC, Scrivener, Skype, Spotify for Linux; I think they all qualify as quite usable applications.
On the other hand, in GTK you have GIMP and Inkscape, which aren't exactly an UX expert's dream. In Qt you can find similar counterparts in Krita (specially Krita Sketch) and Karbon, which I think are much cleaner.
Counter point: Dirk Hohndel explains how the Subsurface team was able to implement a much cleaner and simpler GUI in QT than in GTK: https://www.youtube.com/watch?v=ON0A1dsQOV0
(I've already posted this link in another comment, but here it is again just for relevance)
Maybe people don't make that many complex GUIs in GTK cause it's just too hard?
Well, I won't deny that there's some truth in what you said, but first a couple of comments about the examples.
Transmission is as much a Gnome as a KDE application. It has both Qt and GTK clients that look the same.
Brasero looks as complex as K3B.
I understand that Skanlite can look intimidating (especially on the Image Intensity properties), but Simple Scan seems simplistic. Scan source, scan mode and scan resolution are important properties when scanning and it's very useful to have direct access to them.
The default view in Digikam is not so different than that from Shotwell, a folder list to the left and the corresponding pictures to the right. The metadata widget is not opened by default.
As jstanek pointed out, even if some things could be made simpler and more polished, it's not so much that KDE doesn't have a clue about design and GNOME knows its stuff, but that they have different objectives. GNOME tries to be as simple as possible while KDE wants to give you power in the friendliest way possible. It's apples and oranges.
I feel uncomfortable with GNOME because I think it treats its users as perpetual newbies. I understand that a person's first use of an application should be made as simple as possible, but then they should be able to require more from their software if they want to. There are some things about KDE applications that maybe you won't find a use for at first, but then you need them and it's great to have them at your disposal.
I don't want GNOME to be like KDE, it's good at what it does even if I don't like it. The reverse holds true, too.
> Well, I won't deny that there's some truth in what you said, but first a couple of comments about the examples.
Well, your comments are on the screenshots, not on the applications. Try to use these applications for a while "to get the job done", you will get what I meant.
I have been a KDE user for years, I even contributed some patches back then. I still prefer Qt to GTK. But I whenever I can I use GNOME applications instead of KDE (with the exception of K3B).
I think the main problem can be traced back to when you say
> [In Skanlite/Simple Scan] Scan source, scan mode and scan resolution are important properties when scanning and it's very useful to have direct access to them.
Simple Scan (the GTK app) presents you two presets (Text and Image) and just guesses the rest of the details for you. And you know what? It gets them right 99% of the times. When it doesn't you can access the usual Preferences pane and modify whatever you want.
As somebody else commented in this thread, the KDE world refuses to have "reasonable" defaults in place, starting from the default theme to the good engineering practice of trying to guess as much as possible before asking questions.
PS: Transmissions was born in 2005 as a neat Cocoa application, GTK for Linux has been added soon after in version 0.6 (2006) and the Qt interface was started only in version 1.6 (2009). This is why it looks so like nice.
I use Transmission regularly. I have tried Brasero, Rythmbox and Simple Scan. These last three aren't bad, I just think that K3B, Amarok and Skanlite offer more and aren't that difficult. I just installed Shotwell to make a more informed opinion.
From what I can see, Simple Scan's "magic" is using a default DPI for Text (150 dpi) with grayscale, and another for Photos (300 dpi) and color. What if I want a light photo for the web, or a photo in grayscale? I think these aren't unreasonable examples at all. I suppose I'll have to use the counterintuitive Text for both examples, but now my photo looks awful on print and it's overkill (and monochrome) for the web! And if I have to go to Preferences for such common examples then it would be better to offer them right there in the main screen. Presets are good, guessing is good if you make the options easily available to tweak them. Simplistic presets and hidden options are not good IMHO.
You see, there's simple and there's simplistic. I already agreed that some options in KDE are overkill and should be hidden by default, but some of them are really useful. For example, why can't I preview a large photo while navigating visually the rest in Showell? It's something I usually do with my photos. With Digikam I just press a button and have that, I haven't found it possible in Shotwell, it's either one large photo at a time or many little photos.
It's not only about the framework, it's about the language too. Qt is written in C++, and so it's hard to use effectively when not using C++. On the other hand, GTK being written in C, it is possible to use it either directly, or through some simple FFI or wrapper from whatever language of choice. That alone is enough of the reason that every non C++ developer prefer GTK.
I'd like to know too, because QT makes the best cross-platform apps. A QT app on OS X feels good to use in a way that other cross-platform GUI apps really don't. But I've never tried to code with it, so I don't know what it's like behind the scenes.
I don't like the license of the pyqt Python binding which forces me to use GPL or pay upfront if I remember correctly.
Also my experience with Qt Designer hasn't been as pleasant as with Glade when it came to dynamic layouts. I've struggled an hour to insert something into a vertical container with no luck.
From what the article says, it seems to imply that simply being in the KDE accounts file (a list of everyone who's able to commit to KDE) puts one in the "KDE" camp. That's almost certainly a bit misleading since many of the early engineering hires at Trolltech were KDE people who for more than a decade have been more "Qt" than "KDE". Also, since there are obvious dogfooding benefits to using a desktop built on the toolkit you develop, there are a good many people who worked for Trolltech (and later Nokia, then Digia) who used KDE and would have accounts created to commit an occasional patch.
A more interesting metric would be to see what percentage of Qt commits come from people who commit more to KDE than they do to Qt (and vice versa). As such, this just seems to establish what everybody already knew -- that the two projects are very intermingled.
But that's not what he wanted to point out, at all. It's not about percentages of contributions. He classified them as coming from KDE or not and wanted to demonstrate that many important Qt contributors started in KDE. If someone started contributing to Qt before they contributed to KDE, even if they contribute 99% to KDE, then they don't count as "a KDE person" for this metric.
As far as I understand, it's a message to everyone who uses Qt. Even those who don't use KDE have an interest in keeping it healthy as many valuable Qt contributors come from there. And the graph supports that wonderfully.
Qt came from Trolltech, KDE was originally just using it. KDE developers being major or majority contributors to Qt has been a more recent and gradual phenomenon. I haven't followed closely, but I imagine it also got a big boost with the governance changes in the last year or two.
I love KDE, except when my graphics card doesn't cooperate with it. When I first tried KDE3 when I installed Slackware the first time I tried Linux it was perfect. Now years later, Kubuntu with KDE4 is perfect. I really love the IRC client. I love Qt as well, I wish Qt Creator had a plugin for developing KDE apps. Great projects that solve many problems.
In my personal experience, Qt can handle buggy graphics drivers better that Gtk . In special with the Radeon drivers, were with GTK you got an unusable screen with deformed menus, and with Qt was fine. Or that with the SVGA driver (yep, not acceleration) GTK runs painful slow when with Qt you run soft and with alpha effects.
"Recently I was trying some statistics on the qtbase-module (where QtCore, QtGui, QtWidgets and so on lives) and was wondering who made them.
Not based on their current paid affilation, like Thiago’s graphs, but if each commit was made by a person coming from KDE.
So, I got hold of Thiago’s scripts, a lovely mix of perl and zsh, and a QtBase git repository. First steps was to try to classify people as person coming from KDE or not. Of course, I’m a KDE person. Thiago is a KDE person. David Faure is a KDE person. Olivier Goffart is a KDE person. Lars Knoll is a KDE person.
By the help of the KDE accounts file, and some of the long time KDE contributors, I got after a half day of work a good list of it. Then next steps was trying to put it into Thiago’s perlscripts
All of it kind of succeeded:
qtbase-KDE.graph
So, KDE people makes up for 40-60% of the weekly commits to QtBase. This is again shows that KDE is important to Qt, just as the reverse is. So, let’s keep KDE healthy.
KDE is running a end-of-year fundraiser over here https://www.kde.org/fundraisers/yearend2014/. Go ahead and donate, and help KDE stay healthy. For your own sake. And for Qt’s."
If you use Plasma Desktop, Okular, Kate, Krita, Amarok , Calligra suite or any KDE product, consider donating.
[0] https://www.kde.org/fundraisers/yearend2014/