Intel Dev: GTK's Biggest Problem, and What Qt Does Better
Freshly Exhumed writes "Phoronix has an article about how Dirk Hohndel of Intel's Open-Source Technology Center has stirred the hornet's nest with a talk at Australia's Linux.Conf.Au (MP4 file) about what he views as the biggest problem with the GTK: he finds dealing with upstream GTK/GNOME developers to be tough, with frequent abuse and flame-wars, with accusations from the developers that "you're doing it wrong." Conversely, he found the Qt development community to be quite the opposite: willing to engage and help, with plenty of application developer documentation and fewer communication problems than with their GTK counterparts."
I don't understand why anyone would use GTK. It's not noticeably easier to use than other toolkits. It doesn't have a "native" look and feel on any system (if you run GIMP on Windows, you'll notice how all the dialogs are much different than what you're used to seeing in other applications). It's cross-platform, but so are Qt, WxWidgets, and probably a bunch of other GUI toolkits that don't come to mind at the moment. So what's the appeal?
Qt, on the other hand, is its own universe. It's written in a weird dialect of C++98 (though I'm sure it works just fine in C++11 these days), it has its own object model, networking stack, container library, threading library, graphics primitive library (i.e. not Cairo). This object model also leaks into its language bindings if you don't want to write your software in C++.
It's the same problem that Java and C# also suffer from: they're not cross-platform, nothing is. What they actually are is their own platform built alongside a perfectly good already-existing one, and you can see the seams.
There's more to each platform's UI than what bitmap you skin buttons and checkboxes with. If you want a cross-platform application, then write a completely different UI for each platform using those platforms' native UI toolkits. Sadly "good enough" is the order of the day here, so you end up with platform-refugee applications that look like shit.
The main reason I don't like C++ (and C, for that matter) is the way they handle unicode. The next reason is the way they handle pointers. (For C++, Templates come in there, too.)
Vala keeps promising to be a good language, but it's been between alpha and beta quality for 5 years now. D is pretty good, but lacks library support. (You can roll your own to C or C++, but it's a real disincentive. And can be quite difficult if your header files have macros.) Ada is ok, and has decent library support, but it's quite verbose, and hard to document (I'm talking about developer documentation, like Javadoc or Doxygen, or even RDoc, not end user documentation). Also, I really like garbage collection, though that's partially a matter of taste.
If I don't need the performance, I generally pick Python as the "least bad". It's not as good as D, but it usually supports the libraries that I need. It's not as good as Vala promises to be, but it's working and well documented NOW. But even Ada has better unicode support than do C and C++.
I think we've pushed this "anyone can grow up to be president" thing too far.
GTK is far from trash. It certainly compiles and links faster than a Qt app. It can build gui's entirely in your c++ code or integrate with glade-tool-created ui which is on par with qtcreator in that respect. It blends well with c++/c libraries. .apk with the AndroidManifest.xml and other Android "deployment" characteristics for plain c++ built-apps.
I have recently delved into gui development with Qt on Ubuntu touch(ubuntu-sdk) and Qt on Android(Necessitas and Qt for Android). I'm not quite content with either. Newer Qt tools force developers to use QML/declarative script. The ide doesn't offer any easy way to use C++ for everything in Android. It's possible, but it's not very well documented. When compiling and Android app without QML/.ui files, the IDE isn't intuitive to use to get what you need to build the minimum
gtkmm has no complications about assembling everything into an apk file. You just assemble everything c++ into your executable or keep them separate. It's the developers choice unlike android's forcing of everything into an apk. I just prefer desktop app development over mobile device development. Qt doesn't save you time with android. You still need to do your homework and learn everything android anyways. i.e. JNI to get access to special non qml apis. There has been recent discussion about difficulty using persistent storage api with qml. That's so 1990's an issue. There are so many ways of skinning that cat with c++ libs of all sorts. boost serialization and mongodb come to mind, but there are so many others. Even golang(higher-level C++-like) has less problems using gtk and serialization than qt/qml and it has even shorter compile/link times than c++. golang/gtk/serialization compile/link time c++/gtk/serialization compile/link time qt/qml serialization compile/link time.
To be blunt, I would rather compile with gtkmm with Ubuntu/Debian on any device mobile/desktop/cloud given the opportunity.
There will be an opportunity to see gtk on ubuntu touch. I would prefer gtk than qt toolkit on ubuntu touch because it would save enormous amounts of time iterating through compiles/links.
Don't call GTK trash and I won't trash QT. They both have their places, but platforms should not impose language choices on developers like android and ubuntu touch did by forcing everyone to use qt. That was a mistake. All this to say GTK has its strengths and weakness and so does qt/qml/declaratives. It's interesting and useful, but doesn't necessarily save the developer time and qt doesn't necessarily give the best runtime performance if an app has qml/declaratives in it when compared with straight c++. If the ubuntu touch team would have stuck with gtk for the touch interface, I believe they would have finished the ubuntu touch/ubuntu edge prototype completely by now. If Android would get rid of all the apk complexity, provided c++-only gui api and stuck to c++ rather than convoluted java/jni/c++, there would have been even more apps in their play store by now. golang will have greater importance on for building guis/apps on all platforms soon enough. go-gtk bindings exist. So do go-qt bindings. One thing is certain. I don't like QML and that's a subjective thing. Knock yourself out with qml if you want but don't impose it on everyone else. That's bad for business. People will walk away if it's the only developer tool option offered for a device.
I feel like all the time I donated helping with gtk questions on the gtk irc channels was useless now. )-:
When it comes to the UI, objects are natural. Every C toolkit goes through hoops to provide you with objects of some kind. Motif, GTK, etc. So why not just use an object oriented language to begin with?
You don't have to use the dark corners of the language. Qt sticks to just the Object Oriented parts of C++, with just a tiny bit of templates. Not a functor in sight (unless you wander toward the totally optional Qt::Concurrent framework). Internally it uses all of the language, but as an API it provides just the object oriented subset.
Don't blame me, I didn't vote for either of them!
Well, it does give some background that he is actually deemed to be employable by intel, rather than some hack pumping out shit in his bedroom.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
You are aware that you this is a project founded by Linus himself and that Dirk is involved with open source development since 1988, often working at the kernel and other core infrastructure you are likely to use if you run Linux?
I somehow doubt that these two are not aware of how open source works. I am further convinced that they are bright enough to figure things out on their own by reading the code and/or using the internet.
Regards, Tobias
What I got out of the talk, GTK vs QT:
GTK
1) Lousy documentation
2) Lousy code
3) Lousy developer community support
QT
1) Good documentation
2) Good design
3) Great developer community support
Are you really saying Linus Torvalds "feels ENTITLED to the time of open source volunteers, when they don't make every effort possible to answer their own question."?!?!?!
Any other developer, you might be able to say that, but Linus wrote the kernel himself, and still answers emails (I've had responses to questions I sent him!)
So, stop justifying and defending the GTK people.
Put it another way. When Linus Torvalds and 3 of the core GNOME maintainers *CANNOT* figure out how to do something, and Linus asks for help from the GTK community and got a "meh", your community sucks.
First I am almost 100% sure that there will be some idiots employed by Intel somewhere. Every big company has some of those around. So "works for company X or Y" is not a qualification in my book.
Second Dirk is making it very clear that he is speaking as a private person about a hobbyist project of his, not as an employee of some company. So there is no reason to bring the company into the discussion. People will misread the headline to mean that this is something that Intel is doing. Just check this thread: One misguided individual is asking: "How many people here flamed Canonical 3 years ago when their developers ditched working on Gnome3 in favor of Unity for this very reason? Are you now going to flame Intel because their developers are saying the same thing?".a couple of comments down. It is not Intel speaking, it is not even "their developers". It is just one single guy speaking about something that is not related in any way to what Intel does. These misunderstandings were needlessly created by the headline.
Seriously: This is slashdot. How many people here on slashdot bother reading more than the headline? :-)
Regards, Tobias