GTK-- vs. QT 325
spirality asks: "The company I work for is getting ready to decide on a GUI Toolkit for
our Computational Modeling Toolkit (CoMeT, www.cometsolutions.com). We would like C++ compatibility and ports to various Unices and Win32 platforms. Not supprisingly we've come up with two choices, GTK-- and QT. I've attempted to compare the two by doing alot of web surfing and searching, but I've come up with things that are consistently one or more years old. So, the question I pose is what are the (dis)advatages of GTK-- and QT, and why would I choose one of these toolkits over the other? Overall functionality, momentum for future growth, ease of use, licensing, and pretty much anything else is relevant to our decision." With QT now at version 3.0 and GTK now in the 1.2.x revisions, maybe it's time to give the two libraries some fair comparison and discuss the new features, advantages, and disadvantages of each?
QT seems to rule (Score:2, Interesting)
I'm not experienced, but as a lay-man, I'd have to say go for QT.
Qt has better documentation (Score:5, Interesting)
Another observation is that GTK-- is much more low-level than QT. If you want to extend it's components you might have to delve into the depths of the gdk library (which, in my view is only a thin wrapper around the X11-libs). QT on the other hand has a very good abstraction of windowing system details. Being mostly a Java programmer, I found the QT model very easy to use.
Of course, YMMV.
What about gimp? (Score:2, Interesting)
gimp is THE flagship gtk application, bar none.
Re:Mozilla (slightly OT too) (Score:3, Interesting)
2. If you actually needed a UI that was as rich and powerful as XUL can provide, why woulld you want to go off an write it al yourself?
3. Are you thinking in terms of writing web pages and CGI that acts as an application, or are you thinking in terms of building your UI into the XUL interface of Mozilla? These are very different things (and both actually have a place in different applications).
QT forces non standard c++ use (Score:2, Interesting)
QT has reimplemented all those things as a rather dodgy set of proprietry classes, which lock you into, for example using QString rather than std::string throughout your application, or doing a lot of extraneous conversions every time you need to talk to the GUI.
In its favour, QT does have much better documentation than gtk--, but all the same, I prefer the standards based gtk--.
Re: OS X port (Score:2, Interesting)
The HUGE disadvantage is that QT programs will never be as fast as "real" Mac programs, because all the UI stuff (bitmaps for buttons, for instance) will eat up memory space and disk access time. The other programs get the UI for free.
It's also a practice Apple doesn't like. At all. Remember the Mozilla port?
There's also the danger that OS X will pick up some new feature, like for instance voice-controlled mouse movement to UI elements or whatever. Every program will magically work with them, except for QT-based programs which will just sit there and look stupid until Troll gets around to update their (closed-source!) Mac port.
Dr. Dobbs articles. (Score:2, Interesting)
Al Stevens provides a column in Dr Dobbs Journal titled "C Programming". In the Sept-Oct 2001 columns he described issues he ran into testing both the Qt and GTK-- class libraries. I do not have the articles here but Al gave some pretty good C++ aesthetical reasons for staying away from Qt. Specifically he mentions having to re-compile some of the Qt libraries so that he could extent their class to properly convert from a STL String to their Qt string class.
He had many other reasons for not using Qt. When I get back to work from this long holiday I will post an outline of his specific reasonings.
Just to clarify. I am not an Al Stevens "fan". The man really seems off his rocker sometimes. However, the articles on Qt and GTK-- were very informative. And yes, I did investigate a few of the items for myself. (Do not trust my word though, get the article, read the article, try it out for yourself!)
Re:Before the flame wars start... (Score:2, Interesting)
GTK-- is not GTK+ (Score:5, Interesting)
Well, nearly. If you're from a standard C++ background (as I am), you will find gtkmm preferable, as they don't reinvent parts of the standard library (eg QList vs std::list), they use namespaces and templates (including giving familiar, STL-style interfaces to container widgets etc), and it's implemented entirely in C++ (whereas Qt is in a C++ like language that must be first preprocessed to produce C++).
But, as someone before me said; get both, try them, see which you prefer - there are obviously people who disagree with me, as KDE and Qt are popular.
Use Mozilla's XPToolkit and XUL (Score:1, Interesting)
Mozilla's XPToolkit is:
- Written in C++.
- Cross platform (Windows, Linux, Solaris, MaxOS, and others).
- Open Source and free of charge.
- LGPL'd - You can link it and distribute it with binary-only applications.
- High quality.
For proof of the last point, try running Netscape 6.2 on Windows, or Mozilla 0.9.x on Linux.
Re:Qt if you need Win32 (Score:3, Interesting)
I've worked on two 1 million+ line sourcebases that were cross platform. One used a commercial porting library that was closed source but we had the source license for it. This was a losing proposition. If there was a bug, we could fix it in the library. However, that was a poor long-term solution because we were just patching the library rather than building a long-term cross platform infrastructure for our product.
The second sourcebase I worked on used a home-grown UI abstraction. This one is a lot better because we have the ability to add or remove emulation as we wish. If we have an OS that doesn't support the services we need, we emulatate it. If the OS does support the services we need, we go directly to the OS and gain native look and feel with much less effort.
For this reason, I recommend libraries that
a) Provide a platform-neutral interface
b) Implement the functionality by eventually calling the OS calls required to implement the functionality
c) Is provided in source form so that you basically "own" the library. That way, any changes you make to the library improve your own long term situation.
The only library I've seen that fits that requirement recently is wxWindows but I haven't used it for a real application so I can't comment on its suitability.
Good luck
Re:GTK-- is not GTK+ (Score:1, Interesting)
In Qt3, you also get STL iterators.
"Qt is written in a C++ like language that needs to be preprocessed"
You know, I keep on reading this, and it is so completely bogus, technically, I must wonder if you actually know what C++ or a preprocessor is.
Moc is not a preprocessor. Moc is a code generation tool. Moc takes as input C++ headers and produces C++ code. It does not produce an "expanded header" like a preprocessor (say, cpp) does.
Saying moc is a preprocessor is as stupid as saying Visual C++'s "application wizard" is a preprocessor.
GTK+ and Objective C (Score:2, Interesting)
Try FLTK (Score:2, Interesting)
Try FLTK { www.fltk.org }
You won't be disappointed with the Fast and Light Tool Kit.
For download, go to ftp://ftp.fltk.org