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 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.
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).
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.
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