●Stories
●Firehose
●All
●Popular
●Polls
●Software
●Thought Leadership
Submit
●
Login
●or
●
Sign up
●Topics:
●Devices
●Build
●Entertainment
●Technology
●Open Source
●Science
●YRO
●Follow us:
●RSS
●Facebook
●LinkedIn
●Twitter
●
Youtube
●
Mastodon
●Bluesky
Catch up on stories from the past week (and beyond) at the Slashdot story archive
Forgot your password?
Close
This discussion has been archived.
No new comments can be posted.
Load 500 More Comments
Full
Abbreviated
Hidden
/Sea
Score:
5
4
3
2
1
0
-1
More
Login
Forgot your password?
Close
Close
Log In/Create an Account
●
All
●
Insightful
●
Informative
●
Interesting
●
Funny
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
byRainefan ( 969597 ) writes:
Why not just use Qt instead? It's LGPL....why people still using GTK?
twitter
facebook
bymoonbender ( 547943 ) writes:
True! And since it now comes with QGtkStyle, which uses GTK+ engines and widgets to render stuff, you can use it and have a nice looking app at the same time.
Parent
twitter
facebook
bypatro ( 104336 ) writes:
I can attest Qt is a very fine GUI toolkit with excellent documentation.
Seems like the "not invented here" syndrome rears its ugly head again, otherwise more people would give it a try instead of Gtk.
byAnonymous Coward writes:
I have to agree with you.
Gnome came in existence because the purity police didnt like the non-free Qt widget toolkit. (how ironic is it that its founder Icaza is now on the other side and being attacked for his hardon for mono in the same way? Poetic justice.)
It seems that even though QT is now under a free software license, a lot of the old bias still exists.
I like the fact that we now have the best of both worlds with QT, both a free software license and
that the phone leader Nokia bought Trolltech because
byslack_justyb ( 862874 ) writes:
I have no idea why GTK+ is still around since Qt went LGPL.
Qt has better documentation [qtsoftware.com] than GTK+. [gtk.org]
As an example, you'd be hard pressed to find a widget in the QT documentation that is not documented. GTK+ has rough around the edges documentation for it's Canvas.
I know that RedHat is putting a lot of weight behind Java technology as one of the first and foremost distros for the OpenJDK. I can attest that the QT Java bindings [trolltech.com] are way better than the GNOME bindings. [sourceforge.net] It would make sense for RedHat to toss weight behind QT. Google already uses QT for Google Earth. [google.com] And KHTML is, sorta, WebKit which is Chrome. It all makes more sense to put our weight in QT.
I've got nothing but love for the GTK+ people. Also, don't kill QT just because of the KDE 4.0 issue. They've made good on their latest desktop, but don't knock a good Toolkit because of the DE.
My two cents.
Parent
twitter
facebook
byDr. Spork ( 142693 ) writes:
I'm puzzled by this myself, but I'm a bit of an outsider and definitely not a developer. Could it be that GTK+ is more streamlined and performs better? If not then I really can't fathom why this GTK+ vs. QT rivalry is being depicted as a battle of near-equals. They're not close!
byc0d3g33k ( 102699 ) writes:
Factor in the tendency of human beings to make non-rational choices and it makes a lot more sense.
byPeterBrett ( 780946 ) writes:
I know that RedHat is putting a lot of weight behind Java technology as one of the first and foremost distros for the OpenJDK. I can attest that the QT Java bindings are way better than the GNOME bindings. It would make sense for RedHat to toss weight behind QT. Google already uses QT for Google Earth. And KHTML is, sorta, WebKit which is Chrome. It all makes more sense to put our weight in QT.
Qt now includes a Webkit-based HTML renderer directly.
QtWebKit [trolltech.com]
Also, yes, WebKit grew out of the KHTML sourcecode, and Chrome is based on WebKit. Isn't Free software great?
bydbIII ( 701233 ) writes:
The original political bullshit over the Qt licence was pretty well irrelevant to anyone that actually read the trolltech licences (which got more and more like the GPL every time). The gnome people (the competant ones that stayed on instead of the political ones that left early and left us horrors like gconf) really just wanted their own environment that looked and behaved differently to KDE in ways they thought were better. When Qt went GPL years ago that didn't change so gnome continued. By then gnome
byslack_justyb ( 862874 ) writes:
wanted their own environment that looked and behaved differently to KDE in ways they thought were better.
You sir have hit the nail on the head. The thing that corporate software fails to understand about Linux is that we are free to implement what we think is best. There isn't a standard to Linux, and there never should be.
But then you have people like Google and Adobe who stoke people in the KDE and GNOME camps to start these rally calls for standard desktops. Next thing you know, you've got yourself a good ol' fashion KDE vs. GNOME debate/flame war.
That's exactly when people start nit-picking each
byLalo Martins ( 2050 ) writes:
Probably because GTK+ is written in a standard language, and Qt is written in a custom, non-standard dialect which nobody else uses, forces you to use weird special-purpose nonsense pre-compiling tools, and doesn't really add anything useful to the parent language.
byslack_justyb ( 862874 ) writes:
Qt is written in C++ with non-standard add-ons to the core of the language which is passed through moc [trolltech.com], a pre-processor, that converts those non-standard elements into compliant C++ code that gcc can process.
I fail to see how this is any different from macro expansion [gnu.org]. Other than the simple fact that macro expansion is defined in the C++ standard and moc is not.
The "special-purpose nonsense pre-compiling tools" are there to make building your program easier. Besides, GTK+ not only came up with "spec
byshutdown -p now ( 807394 ) writes:
I have no idea why GTK+ is still around since Qt went LGPL.
Gtk is written in C, and has C API. Qt is written in C++, and has C++ API. In general, it is much harder to access C++ APIs from various high-level languages with FFI (Python, Ruby etc) then it is to access a C API.
byslack_justyb ( 862874 ) writes:
In general, it is much harder to access C++ APIs from various high-level languages with FFI (Python, Ruby etc) then it is to access a C API.
I don't think that's an argument for Gtk+ vs. Qt as it is an argument for C vs. C++.
The argument is pretty moot when you consider PyQT [riverbankcomputing.co.uk], QtRuby [kde.org]. The only problem with C++ is name mangling [wikipedia.org]. This can be solved with a pretty simple extern "C" call.
byshutdown -p now ( 807394 ) writes:
The argument is pretty moot when you consider PyQT [riverbankcomputing.co.uk], QtRuby [kde.org].
Have you looked closely at either one of those, especially the way they handle Qt signats/slots? Here [riverbankcomputing.co.uk] are PyQt docs. Highlights:
Qt signals are statically defined as part of a C++ class. They are referenced using the QtCore.SIGNAL() function. This method takes a single string argument that is the name of the signal and its C++ signature. For example:
QtCore.SIGNAL("finished(int)")
...
Qt slots are statically defined as part of a C++ class. They are referenced using the QtCore.SLOT() function. This method takes a single string argument that is the name of the slot and its C++ signature.
QtCore.SLOT("done(int)")
...
Many of Qt's features make use of its meta-object system. In order to make use of these features from Python it is sometimes necessary to make certain Python objects (i.e. QObject sub-classes, properties and methods) appear as C++ objects. In particular it is sometimes necessary to define a C++ function signature that a Python method emulates ...
@QtCore.pyqtSignature("int, char *")
def foo(self, arg1, arg2):
...
So you have to deal with C++ function signatures while coding in Python - great.
For QtRuby, the situation is exactly the same. I won't go into details, but here's just one example from the docs [kde.org]:
Qt::Object.connect(@colormenu, SIGNAL("activated(int)"), self, SLOT("slotColorMenu(int)"))
It should be noted that QtRuby docs say that "future version of QtRuby will allow Ruby type signat
byslack_justyb ( 862874 ) writes:
Wait. I don't see where the comparison is. Both took two lines (Qt and GTK+.) I'm wondering where the argument is?
byshutdown -p now ( 807394 ) writes:
All Qt examples have to spell out C++ slot signatures explicitly, using C++ type names, both when declaring and when using. E.g. activated(int), or pyqtSignature("int, char *"). In Gtk, slots just have names, and that is all there is to them.
Simply put, Qt wrappers cannot escape the need of exposing the fact that the underlying framework is written in Qt. You still have to look up those signatures in C++ Qt docs. On the other hand, Gtk wrappers are opaque - there's nothing in them that hints at the fact tha
byslack_justyb ( 862874 ) writes:
Your argument was originally that it was harder to access C++ API from language bindings. It's not harder but it comes with a trade-off. You loose some of C++ flexibility moving to another language. You don't loose that same flexibility in C because you never had it to begin with.
What I am saying is that if you decide to give up some of the features of C++ then you'd have an implementation that matches C bindings in syntax.
But it's all just syntax sugar really. C++ has the syntax to make object ea
bysricetx ( 806767 ) writes:
QT is probably the best GUI toolkit in history, in my opinion. Since it's now available under the LGPL license, I have to assume that the development project the whiner from Google is talking about was done before the LGPL QT 4.5 version was released or is not written in C++. Standardization is fine and all, but please, please don't standardize on GTK. Take a look at the hideously ugly GTK file picker for an example of why the usability of GTK UIs leaves something to be desired.
Parent
twitter
facebook
byjbolden ( 176878 ) writes:
No his problem is that QT has an execution loop which incompatible with the Chrome engine. What makes QT so cool for event driven programming is an event handler that can't be easily changed to match the event handler in Chrome.
Parent
twitter
facebook
byTheSunborn ( 68004 ) writes:
Citation needed.
Do you have any description about what this problem with the Qt event loop should be?
byjbolden ( 176878 ) writes:
Not beyond what was in the original article.
byswillden ( 191260 ) writes:
Not beyond what was in the original article.
Which article? I don't see any discussion of Qt even loops either in the article or in the links from the article. Excuse me if I missed something obvious, but I can't find what you're talking about.
byjbolden ( 176878 ) writes:
original thread [google.com]
byTheSunborn ( 68004 ) writes:
I may be blind, but I could not find any complain about the Qt event loop there. (Or any reason at all, for their choice of Gtk over Qt).
byjbolden ( 176878 ) writes:
You will need to port the message pump in base/. This means writing
a version of what would happen if you were to call
QApplication::exec(). Too much of our code requires our own custom
message loop and some of the threading support it has. You might want
to get this part down before anything else because I have vague
memories of not being able to re-implement the main Qt runloop on one
of my side projects.
byultrabot ( 200914 ) writes:
No his problem is that QT has an execution loop which incompatible with the Chrome engine. What makes QT so cool for event driven programming is an event handler that can't be easily changed to match the event handler in Chrome.
Qt actually runs the glib event loop these days. You can easily verify this by kill -ABRT'ing a kde app and checking the core dump; this just in from kate:
#8 0xb5df874b in IA__g_poll (fds=0x9c225c8, nfds=6, timeout=25243) at /build/buildd/glib2.0-2.20.1/glib/gpoll.c:127
#9 0xb5deaf82 in g_main_context_iterate (context=0x9778e90, block=1, dispatch=1, self=0x9776f40) at /build/buildd/glib2.0-2.20.1/glib/gmain.c:2761
#10 0xb5deb268 in IA__g_main_context_iteration (context=0x9778e90, may_block=1) at /build/buildd/glib2.0-2.20.1/glib/gmain.c:2511
#11 0xb6a5f438 in QEventDispatcherGlib::processEvents (this=0x9763c68, flags={i = -1074473992}) at kernel/qeventdispatcher_glib.cpp:323
Parent
twitter
facebook
byjbolden ( 176878 ) writes:
Interesting, you should probably reply to the original post on the Chrome site.
byspitzak ( 4019 ) writes:
Sounds like KDE modified Qt.
Our plain Qt 4.3.3 application if interrupted shows this on the stack:
#0 0xb805e430 in __kernel_vsyscall ()
#1 0xb762ddf1 in select () from /lib/tls/i686/cmov/libc.so.6
#2 0x08a9e6c4 in QEventDispatcherUNIX::select ()
#3 0x085cb93e in QEventDispatcherX11::select ()
#4 0x08a9f880 in QEventDispatcherUNIXPrivate::doSelect ()
#5 0x08a9fd36 in QEventDispatcherUNIX::processEvents ()
#6 0x085cbb56 in QEventDispatcherX11::processEvents ()
#7 0x08a7b571 in QEventLoop::processEvents ()
#8
byLouai ( 1243284 ) writes:
Sounds like KDE modified Qt.
No. Qt has several event loops - it will default to the glib-based one if glib is available at compile time. It will fall back to the generic Unix event loop if glib is not found. You can also disable the glib event loop by setting the environment variable QT_NO_GLIB if you need to - for example debugging is simpler with the generic Unix main loop.
This was developed by Trolltech back in 2006, see here [trolltech.com]. Interesting quote: the ideal would be for all applications on the X11 desktop to use the same event dispat
byChunderDownunder ( 709234 ) writes:
That sounds backward to me.
You're advocating Qt, a toolkit used by thousands of applications, break its event paradigm to fit in with Chrome, an application?
Without knowing the technical details, it sounds to me that Chrome is inflexible with respect to integrating with Qt. Or rather, certain architectural assumptions were made that fit well with Win32 but not other environments.
byjbolden ( 176878 ) writes:
I'm not advocating anything I'm answering a question from GP why QT wasn't chosen. I don't think QT should change to fit Chrome now that you ask. You can look at Chrome as inflexible but at the end of the day the engine organization is the key feature. Which is to say I think they likely did the right thing.
bymixmasta ( 36673 ) writes:
The file picker is not ugly per se ... rather I think you mean that it is a poor design. That may be true, but I suspect it has little to do with the underlying toolkit.
byblind biker ( 1066130 ) writes:
Take a look at the hideously ugly GTK file picker for an example of why the usability of GTK UIs leaves something to be desired.
True that - but the thing is so fugly that I often think it's actually a practical joke on the part of the guy who developed that POS. I think he's laughing his head off multiple times a day. Or maybe he's weeping: "I created a monster!!!" depending on his morals.
● your current threshold.
byarth1 ( 260657 ) writes:
Because for large projects, porting from C to C++ can be non-trivial?
Anyhow, I don't see the need to polarize it between the two. The beauty of the open source movement is that there is room for an endless amount of forks. It's called evolution. The weaker ones die out, while the stronger ones grow and fork. "But how am I to choose what to use then?" I hear the closed source advocates cry. Simply put, you too have to evolve, and be able to adapt to the APIs that are there tomorrow. If you can't, your
byultrabot ( 200914 ) writes:
Because for large projects, porting from C to C++ can be non-trivial?
What's the nontrivial part about that? You can switch to g++ from gcc quite easily, and the errors emitted by the more strict compiler can be fixed by any junior developer (some casts, basically).
bycyba ( 25058 ) writes:
The problem lies in errors that won't show during compilation...
bybonch ( 38532 ) writes:
Ubuntu is the biggest example of what you might consider a "desktop standard" in the wild and crazy Linux world, and Ubuntu uses GNOME and GTK+. It's not surprising Google went with it. It's amusing you asked why people are "still using GTK," as if Qt has somehow surpassed it or rendered it obsolete.
byFlyingBishop ( 1293238 ) writes:
As an end-user, speed is pretty much all I care about.
Especially when the difference between Gnome and KDE is easily a factor of 4.
bymarm ( 144733 ) writes:
Which is one of the many reasons I use KDE. Startup speed (KDE 4.2 vs. GNOME 2.26) is about the same on my Ubuntu jaunty box (about 15 seconds from login), but once the DE is booted, KDE apps are literally several times faster to start than the equivalent GNOME apps. e.g. Amarok starts in 2 seconds, while Rhythmbox (which is throughly inferior anyway) takes about 7. Konqueror starts in another couple of seconds, Arora also takes about 2 seconds, Firefox takes about 8 or 9. Once upon a time it used to b
byblind biker ( 1066130 ) writes:
Actually, in the past Gnome apps (and the Gnome desktop) were noticeably slower AND buggier than KDE. This was the situation from the very beginning up to a couple a years ago when KDE screwed the pooch a bit and computers became fast enough to cope with Gnome crud - so Gnome pulled slightly ahead on speed.
But traditionally, Gnome has always been about buggy and slow.
byFlyingBishop ( 1293238 ) writes:
Rhythmbox took about 5 seconds just now. Amarok, on my machine, will take about 10, and it locks up at least once every other week so I have to kill it.
Ktorrent is a similar story with respect to transmission. I like their features, but they're slow and buggy. I suspect it's because I have one core, and no one is debugging on single-core machines.
byDaishiman ( 698845 ) writes:
The Qt purists obviously have every reason to defend the superiority of the toolkit in technical terms, and they'd be right about that. Nontheless when making large projects there are more other variables in play which may be more important.
Specifically, more people use a desktop with a GTK base than Qt. It's pretty much as simple as that. GTK may not be as shiny, but it doesn't preclude from being an extremely functional and consistent system that's well documented and tested.
Is Qt as well tested and d
byultrabot ( 200914 ) writes:
But the fact is that if you use it on a GTK desktop, people will notice, and such is life that GTK is the de facto standard.
Qt apps actually look like gtk apps on Ubuntu Jaunty (Qt 4.5). This is a relatively new development, so you are forgiven for making the false assumption here ;-).
bypembo13 ( 770295 ) writes:
And Qt support Gtk, Win32 and Coca.
byAleBaba ( 1566049 ) writes:
Well, the real question is: Why?
Ubuntu users got their Firefox/Iceweasel/Ubufox with GTK-Toolkit. On the other hand, if I had to choose between Konqueror or Chrome I'd rather take choose Chrome (provided it was stable and available).
Lucky me, I prefer Gnome and Firefox.
●h your current threshold.
byultrabot ( 200914 ) writes:
Why not just use Qt instead? It's LGPL....why people still using GTK?
Because MOC sucks ass.
The *one* extra level in stack frames you'll see from metaobjects is peanuts compared to the horrors of all the boilerplate crap you have write out in your source code to support the hackjob OOP we call GObject.
bystatusbar ( 314703 ) writes:
moc exists only because older c++ compilers could not compile anything like boost's "signals2" [boost.org] library. Now every c++ compiler available supports templates enough to make moc redundant and silly. And in fact signals2 is more featureful than moc's signals and slots implementation.
--jeffk++
byJamesP ( 688957 ) writes:
Because MOC sucks ass.
The *one* extra level in stack frames you'll see from metaobjects is peanuts compared to the horrors of all the boilerplate crap you have write out in your source code to support the hackjob OOP we call GObject.
THIS THIS THIS THIS!!!!!!!!!!!!!
Playing with OO in C, at the level GTK/GObject does is insane, stupid, etc. There are native OO languages (and C++, which is painful but good enough) USE THEM.
byXabraxas ( 654195 ) writes:
People always say this like it is easy or even worthwhile to reprogram their entire application to work with QT instead of GTK. It makes even less sense when you realize that Gnome is pretty much the default desktop now whether people like it or not.
●th your current threshold.
There may be more comments in this discussion. Without JavaScript enabled, you might want to turn on Classic Discussion System in your preferences instead.
Slashdot
●
●
Submit Story
It is much harder to find a job than to keep one.
●FAQ
●Story Archive
●Hall of Fame
●Advertising
●Terms
●Privacy Statement
●About
●Feedback
●Mobile View
●Blog
Do Not Sell or Share My Personal Information
Copyright © 2026 Slashdot Media. All Rights Reserved.
×
Close
Working...
Working...