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?
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).
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
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!
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.
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.
Absolutely.
One important thing to note about Qt is the fact that it ain't a wrapper around existing GUI APIs. It emulates the different GUIs out there, so it does the drawing itself, avoiding going through some additional API layers. That translates into a fast and responsive GUI.
I tried it on both Windows and Linux using the platform's native GUI and GUIs from other platforms, i.e. the Motif or CDE style on Windows, the Windows style on Linux. It is very convincing and very fast.
When performance matters, I definitely go with Qt.
Watch out for that "non-commercial" license on Windows though. It might not be appropriate for what you are doing. Your company will probably have to acquire a Qt license for Windows.
Just because your voice reaches halfway around the world doesn't mean you are wiser than when it reached only to the end
...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.
..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.