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 actually prefer GTK+ and I think it's a better bet long-term, but I don't think the cross-platform aspect of the library gets much developer attention.
Being cross-platform is a major selling point for commerical Qt users, however, so if you need your apps to work on Windows then it's clearly the way to go.
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
You may also want to take a look at the wxWindows toolkit. It's a wrapper over what's available on a given platform (the native API in Win32, GTK in the Unix world, and there's a Mac port in progress, I believe). Good stuff, definitely, especially if what you want is C++ and portability. Note that your apps will look totally windowsy on win32, so your users will not be confused by their look.
-- B.
This sig does in fact not have the property it claims not to have.
To pick up your point on licensing, Qt is either GPL or pay. So if your application will also be GPL, it's free, if your application will not be GPL you will have to pay up for Qt. GTK is LGPL AFAIK (enough acronyms for you? ;-) so that will not stand in the way of making your app non-free.
BTW, if you know C++ and want to get to know a bit about Qt, they have a pretty good tutorial online here. Just walking through the examples made me realize just how cool it is, and how much you can do in just a few lines of code.
If you intend to develop a closed-source product, the licence of both library will probably need to be evaluated too. If you go for
an open licence, then it's of minor importance.
(Qt requires licencing fees if you want to keep
your sources closed).
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.
I worked on a rushed project earlier this year, and used the gtk-- C++ wrapper for GTK, as well as the gnome-- wrapper (then still very much under development) for the Gnome libraries, specifically the canvas.
Personally, I found it frustrating to use. As these wrappers are still being worked on, the documentation is sketchy. The object-owning semantics are confusing (at least to me) - I was forever leaking memory or prematurely destroying objects. Trying to destroy something from within a menu callback I recall was particularly noisome. The gnome-- canvas wrappers were a moving target, though they may have since stabilised, and didn't fully expose the canvas API. Writing one's own canvas items is done in C, and then wrapped.
Perhaps with more persistance I might have figured out how to set up keyboard acceleration, but it is at anyrate a real battle to find documentation that explains what is going on with it. AFAIK, there is no straightforward way of making a multiple file selection in GTK+ 1.2. In gnome canvas (not GTK+, but a close cousin) there is promised functionality that is simply not implemented - I'm thinking here of smoothed lines, for which the code reads:
I haven't used QT yet. It certainly looks pretty, and a quick glance at the example code and docs provided seems to indicate that it's not too complicated, and well documented. I'd certainly shy away from GTK+ if a C++ interface is required.
The new version of GTK under development should address many of the shortcomings of the current toolkit, and includes goodies such as Pango. It is not yet in a stable state, however, with the API still undergoing final tweaking I believe.
If you want cross platform compatibilty with C++, then check out wxWindows. It has ports to Windows, MacOS (9 & X), UNIX + Motif, UNIX + GTK. It also has a very well developed Python binding -- so well developed that quite a few people want it adopted as the official Python GUI instead of TKinter.
-- Help Digitise the Public Domain at DP.
My suggestion - try them out.
;-)
Come up with a few small use cases and let your developers loose on everything you can get your hands on. Both Qt and GTK+ are freely available enough for that to be a useful exercise.
You might find that, while Qt has nicer abstractions, and provides a familiar set of classes which are (IMO) far superior to MFC... perhaps GTK has a slight edge for lower level work (which it sounds like you might get involved in). Also, see which interface builder tools your team feels most comfortable with.
The problem with this question is that the replies are likely to degenerate quickly into a C vs. C++ rant-a-thon. Yes, GTK is entirely written in C. But it *is* object oriented. It seems strange to everyone at first, but just because a language doesn't support particular features, doesn't mean that you can't use a particular programming style. OO methodology is just as relevant to C programmers as to C++ or Java programmers.
If your programmers are good, they'll write good code whatever the toolkit. Just make sure everyone thinks that they got a say in the decision.
These sigs are more interesting tha
AFAIK, the Win32 port of GTK+ is more or less a one-man show, making GTK pretty unstable and lagging behind on Windows.
In addition, Qt now has a Mac OS X port.
Add this to the excellent commercial support from Trolltech.
Design and language issues not taken into account.
An example is the Komodo IDE by ActiveState, which uses XUL.
XUL is the next generation browser application platform. Simply speaking, the Mozilla team chose an approach very similiar to JAVA to come closer to a platform independent graphical user interface:
XUL goes one step farther, as there is no compilation step.
The XUL application implementation language is a XML language that together with cascading style sheets and JavaScript glue will yield an application one starts in the browser by opening the .xul document.
A possible advantage of XUL might become the relative ease of application development, change and distribution.
Possible problems will be similiar to the ones known from JAVA. The qualitiy of XUL applications will stand and fall with the quality of the XUL implementation for a specific platform, which right now means the quality of its Mozilla or Netscape implementation.
Of course, compared to JAVA, which has underwent several larger development cycles and now features mighty libraries, XUL is a bleeding edge technology at its beginnings.
However it is still possible to make direct use of the various Mozilla widgets as well from C++.
Developing for a professional product I would always go with as many professional tools as possible.
To me QT seems to be the FAR better decision. It has true interoperablity between Win32, MacOS X and X11.
QT is C++ from the ground up, GTK-- is wrapping GTK++.
Furthermore with GTK you definitely write more code to accomplish the same.
QT 3 gives you access to SQL-databases from its widgets.
QT comes with a very good interface builder.
QT based programes feel snappier than GTK based ones.
One drawback might be that you have to preprocess (actually your Makefile has to) your code before its ready for the compiler, but that's not a big deal.
With Kdevelop you have access to a very good IDE.
One thing I don't know is how QT works in terms of different GUI threads, but I neither know for GTK.
So please, go with QT and be happy
A much harder decision would be: What should I use for my Web-Frontend, mod_perl or PHP... but that's a different story!
It exists, but I don't think it's maintained as well. The primary developers don't really care about Win32, so maintaining it is left to a few masochists :-).
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
I'm not trying to sound stupid or off-topic here, but have you considered Mozilla? Beyond ther browser, they've developed a really interesting cross-platform C++ (and JavaScript) development platform. For a start there's a cross platform implementation of COM and you can develop your UI's in an XML dialect called XUL.
Don't forget that an all-new GTK+ version is just coming out, a cleaner design, vastly improved i18n support, and all. I suggest you look at GTK2 (and it's C++ wrappers) as well, as this is what's going to be used, rather than the current version.
/Janne
Trust the Computer. The Computer is your friend.
...go for Qt. Gtk, IMO, has the huge disadvantage that the current 1.2 revision doesn't support Unicode, whereas Qt fully relies on it and even provides GUI-independent helper classes for all kinds of Unicode conversion that you can use anywhere in the program. This would also help for the mathematical symbols that you probably want to display. It looks like Gtk2 will use Unicode and Pango, thus potentially blowing away the competition, but as long as there's no stable version of Gtk2, I'd go for Qt.
From a conceptual point of view, I like Gtk-- better. It actually uses the modern C++ language, including the C++ type system. This way you avoid the need for a preprocessor, and get static typechecking instead of "dynamic typechecking" (i.e. "the user does the checking"), which is the entire point of using C++ in the first place. It also use the standard C++ library instead of duplicating it poorly, so you don't have to deal with multiple string types and the like. Since the application is a GUI frontend to a library written in standard C++, using the standard C++ library classes, this matter a lot. Qt is written for an ancient subset of C++, something closer to "C with Classes" than the C++ standard.
However, Qt is simple to use, well documented, and have stable API's. In practice, these make it much easier to use than Gtk--.
As an extra plus, Qt is GPL and therefore more gnulitically correct than Gtk--, which is only LGPL.
I agree with you 100%. I've neve used GTK, nor do I know anything about it, but I seem to recall that a friend of my brothers girlfriend said he heard from someone that it was rough around the edges and had no development roadmap for the future. But, on the other hand, I did read an article on ZDnet a couple of years ago about QT, so I would say that it's a much better platform.
Qt is 3.0
Gtk is 1.2.x
Sure it's friday, but come on, thats easy 3.0>1.2, so the choice must be Qt!
Same reasoning shows that Windows 2000 are MUCH better than Windows 98 which in turn is slightly (by 3 point) better than Windows 95, which again are MUCH better than windows 3.11.
Sigh. Does you youngsters not learn anything today?
Thomas S. Iversen
I have been using Qt for some years now starting with Qt 1.0 some years ago. I have also tried to both patch GTK+ programs and in one instance port one of my Qt applications to GTK+ (I was preferring gnome at the time).
The advantages I can see from using Qt is:
* Superb design. The OO design of Qt is really thought out. There are virtual function to do all the basic things you can think of and if you think of something really clever there are lowlevel routines to do that too.
* Superb documentation. A comprehensive, hypertext help and in Qt3 an included help browser. This is really an advantage since GTK+ not really being supported by a commercial entity suffer from lots of "I'll rather code than document" in the libraries.
* Good migration path to new versions. I have a program consisting of ~100000 lines of code (An Oracle client http://www.globecom.net/tora) which I migrated to Qt3.0 in about 2 hours, some of that time was spent using Qt3 specific features also like docked windows where appropriate.
* Not only a GUI toolkit. It also includes primitives for handling threading, I/O (files and sockets), UNICODE conversions and also some basic template classes made mostly obsolete now that STL is starting to actually work in GCC.
* Truly multiple platform. The application above was ported to Windows in about a day, all of the problems related to the fact that Visual C++ understands a different dialect of C++ than most of us are used to and that took some time write around, none of it was Qt specific. The extra thread and I/O classes really helps here as well.
/Mauritz
GlobeCom AB
...as everyone knows that the software with the highest version number is obviously the best.
(Score:-1, Sarcastic)
..make your application interface independant. The idea is to make your program a basic application that can run without a gui. The gui is then a plugin or something. That way you can take one application and write a gui using gtk, QT, win32, whatever you want and never have to rewrite the application. This is how licq works. The licq application is stand alone and you can download interface plugins for it, QT plugins, gtk plugins even command line plugins. This is great for me since QT doesn't run on the platform I use, so I have to use the commandline plugin.
Don't lock yourself into one gui and hope that it will cover all the platforms you need, most of them don't. Allow any kind of gui to work with your program, not only is it more cross platform compatible, but other people can create guis for your application without ever have to touch the applications code.
Outdoor digital photography, mostly in New Engl
I regularly use the GIMP on Windows, and at least for me, it's at least as stable as any of my other Windows programs. Remember one thing: if it crashes running under *nix, people will get mad. Things aren't supposed to crash under *nix. If it crashes under Windows, people will more than likely say "humbug", restart their computer, and go on with things.
Now that we have been using Gtk--, we have relatively few regrets. The documentation was poor, for a time, but they have semi-recently improved the documentation, and it is quite workable. There are some small things that you would think would be done differently, but overall they are very minor and easy to live with.
Since we aren't concerned (yet) with porting our software, that wasn't much of an issue. Of course, your situation may be different there.
Finally, echoing what other people have said here, Gtk-- can be quite low level at times. I would recommend that if you decide upon Gtk--, you do what our company has done. We created our own set of libraries that provide standard looks to things with minimal hassle, derived from the Gtk-- classes. An example of this would be windows. We have our own window class that sets up standard options that Gtk-- allows to vary considerably. (Additionally, it automatically checks for certain keystrokes, like the F1 key, and signals that fact.) Making a button class would be similar, so all of your buttons are approximately the same size, have the same shading, etc. We were late in figuring this out, but it has greatly simplified our code and made our program look much more consistent.
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.
[disclaimer: my real email address is @wxwindows.org]
> Not supprisingly we've come up with two choices,
> GTK-- and QT.
This surely is surprizing to me. I wouldn't consider GTK-- a serious choice for writing Win32 programs - sure, it "works", but have you seen it and/or used any GTK+ programs under Windows? But I would consider FOX, FLTK and wxWindows as serious contenders to Qt.
I can't speak of the others but let's compare wxWindows and Qt:
1. wxWin has almost all of the features Qt has
(it doesn't have some, but then it has some extras)
2. wxWin is free (as in beer too) for all uses
3. wxWin has native LNF, even under Windows XP
(which can be a serious advantage if you
target this platform).
But try it for yourself - wxWindows 2.3.2 is scheduled for Dec, 2 and has quite a few interesting new features. And see www.wxwindows.org for more info.
GTK:
GTK
QT:
QT
Excellent QT Tutorial
wxWindows:
wxWindows
wxPython
Mozilla:
Mozilla
Cross-platform implementation of COM
develop your UI's in an XML dialect called XUL
Others:
FLTK
Fox Toolkit
Side-by-side comparison of GUI Toolkits:
The GUI Toolkit and Framework Page
I needed this list for my own use. Maybe it will be of interest to you.
Bush's education improvements were
No, it's not. All the free licenses have that. non-commercial, free, educational, etc. Check the TrollTech General FAQ
That, along with the FAQs, statements, etc. from Trolltech's past seem to make it clear. Go check their site yourself. Perhaps have a lawyer check the mentioned Professional and Enterprise Edition licenses and let us know if you're right and Trolltech is wrong.
I'm not trolling, just trying to point out issues with the Qt licenses. If you start with a commercial license and never want to ship shareware with it, or if you start with the proper free license of your project and keep it open-source forever, then it's not bad.