Slashdot Mirror
GTK-- vs. QT
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?
I've recently got my Sharp SL-5000D which comes with a cute embedded version of QT. I'm starting to play with it some more, and I have to say I'm impressed. I've not done much GUI dev. under 'nix before, but I've followed many threads in the past elsewhere that suggests GTK is a hodge-podge and is getting out of control, with no coherent design.
I'm not experienced, but as a lay-man, I'd have to say go for QT.
I have only scratched the surface of both GTK-- and QT, but I found QT to have a *very good* documentation. It has a complete class hierarchy documentation and comes with a load of example programs.
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.
Didn't they port gimp to win32?
gimp is THE flagship gtk application, bar none.
1. Have you used anything built on top of Mozilla (e.g. Komodo) or are you just flaming because it feels good?
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).
The big difference is that gtk-- is based on the C++ standard library, and so allows you do use familiar and efficient constructs like std::vector, std::string and so on.
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--.
The downside is that QT is slow, which is because they fake all the high-level UI calls with low-level code. That's how you can run a QT program on the Mac, but with Win32 or Motif look-and-feel.
:-/
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.
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!)
"A sample size of one is really just statistical masturbation."
A lot of people seem to have missed that the question was asking for opinions on GTK-- (now gtkmm), not GTK+. The difference being that gtkmm is the C++ interface to GTK+, so no C vs C++ dilemma exists here - both are C++.
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.
Mozilla's XP (Cross Platform) Toolkit would seem to fit your needs.
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.
Relying on a library that does UI emulation is a double-edged sword though. Since the emulation effectively replaces the native UI code, your app will lose all leverage from upgrades to the OS services. For example, an app that natively calls the Windows menu manager will automatically get the new windows XP look and feel for its menus. However, an app that uses a library that emulates the native OS will still have the old look and feel until the emulation library is upgraded. Since look-and-feel issues are the biggest gripes you will get from users when developing a cross platform library, this is not a decision that should be taken lightly.
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
As it was mentioned before (and many times) GTK+ is coded in C, but is still object oriented. It uses an ad-hoc object system with dynamic typing, single inheritance. It's clean, but it's rather clumsy looking. If it had some kind of pre-processor it would look much nicer... wait! that would be just objective C! Wouldn it be nicer to have implemented gtk in Objective C? Just a random thought..
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
Muchas Gracias, Señor Edward Snowden !