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 if you need Win32 (Score:5, Informative)
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.
wxWindows (slightly OT) (Score:5, Informative)
GTK Seems solid, but slow on Solaris (Score:2, Informative)
--
Dooferlad
licensing (Score:5, Informative)
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 [trolltech.com]. 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.
GTK+ C++ wrappers (Score:5, Informative)
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.
A third alternative... :) (Score:3, Informative)
If you want cross platform compatibilty with C++, then check out wxWindows [wxwindows.org]. It has ports to Windows, MacOS (9 & X), UNIX + Motif, UNIX + GTK. It also has a very well developed Python binding [wxpython.org] -- so well developed that quite a few people want it adopted as the official Python GUI instead of TKinter.
Mozilla (slightly OT too) (Score:5, Informative)
An example is the Komodo IDE [activestate.com] by ActiveState, which uses XUL.
XUL [xulplanet.com] is the next generation browser application platform. Simply speaking, the Mozilla [mozilla.org] team chose an approach very similiar to JAVA [sun.com] 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++.
Re:What about gimp? (Score:5, Informative)
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 :-).
Re:Licencing (Score:2, Informative)
New GTK+ (Score:4, Informative)
/Janne
Re:Qt if you need Win32 (Score:5, Informative)
QT has an easier to program API, is quick to program in, has great documentation, has support, has a huge wealth of existing code examples, and is supported on Windows. GTK is not supported on Windows, and is a one-man port job. Fine for free software like the gimp, but not for a commercial application. Don't save a couple of grand on the GUI toolkit and get yourself a lot more costs in support that you have to provide because of problems.
GTK2 might solve a lot of the problems in the current GTK of course, but I am not qualified to comment about that. And do you really want to program using a just finalised API?
QT just does things right. 'nuff said.
Re:licensing (Score:3, Informative)
Just remember that you only need to give your source to any entity you give the binary to. Being GPL/LGPL doesn't mean you can't use it for business use; the license is entirely transparent for apps which will only be used internally.
Re:I switched from Gtk-- to Qt (Score:3, Informative)
The LGPL was written specifically to get around the 'viral' aspects of the GPL. Meaning that while Gtk-- gives you the option to GPL your product, QT does not. With QT you MUST use the GPL... unless you pay Troll Tech an arbitrary, although currently quite reasonable sum.
Re:What about gimp? (Score:2, Informative)
GTK porting was mainly done by one single person.
I think, there are a few other GTK based apps, which Windows Users would like. But without a stable GTK on Windows?
Bye egghat.
Some points from using Qt. (Score:5, Informative)
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
My company went through this... (Score:5, Informative)
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.
Cuz it's crap (examples failed when I tried them) (Score:2, Informative)
GTK--/Qt are not the only choices (Score:3, Informative)
> 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.
More complete list of links: (Score:5, Informative)
GTK:
GTK [gtk.org]
QT:
QT [trolltech.com]
Excellent QT Tutorial [trolltech.com]
wxWindows:
wxWindows [wxwindows.org]
wxPython [wxpython.org]
Mozilla:
Mozilla [mozilla.org]
Cross-platform implementation of COM [mozilla.org]
develop your UI's in an XML dialect called XUL [mozilla.org]
Others:
FLTK [fltk.org]
Fox Toolkit [fox-toolkit.org]
Side-by-side comparison of GUI Toolkits:
The GUI Toolkit and Framework Page [geocities.com]
I needed this list for my own use. Maybe it will be of interest to you.
Re:wxWindows (slightly OT) (Score:5, Informative)
The license it's under is acceptable (to me), and there are working large apps such as Audacity [sourceforge.net] out there.
When I discovered all of this, I decided to look into the technology side of things. To throw more goodness at you, let me say reiterate that the toolkit looks native to your environment which is a big win. On top of that, it lets you do things which aren't lowest common denominator and exist in only one or more environments, such as toolbar icons in Windows.
I also like the class hierarchy. I had never done GUI programming before but everything came across rather clearly when I started reading the documentation.
Additional to all the "low level" GUI junk, it also contains some routines for networks and a portable wxString class which is a lot like stl::string with more methods added. I found myself using this almost immediately and I haven't looked back.
It's worth learning this stuff just to get away from MFC without taking the speed hit of learning Java/Swing and having to learn a whole new language and culture. There is even some boasting about how 'the Java honeymoon is over' on the page, stating that wxWindows is actually a more portable toolkit. :) ymmv.
There are both Python and Perl bindings for it. I haven't looked into either really, but at least the Python ones seem to be of high quality as a number of people on the mailing list are Python programmers.
Check it out [wxwindows.org] before coming to a conclusion of what toolkit to use. It's worked for me.
Re:wxWindows (slightly OT) (Score:5, Informative)
Al Stevens took a look at both Qt and Gtk-- in the September and October issues of Dr Dobbs Journal.
What he didn't like with Qt:
The last (I think. I only have October) refers to that Qt takes ownership of objects instantiated on the heap i.e. new without a corresponding delete. Which means you have to do all instantiating on the heap because there is no portable way for Qt to know if it is on the stack, external, or static memory.
He thinks Gtk-- remedy all these problems and he actually found the tutorial funny albeit a work in progress.
Re:GTK-- is not GTK+ (Score:2, Informative)
First of all that is a serious exageration! Second it does not matter even if from a esthetical point if view the preprocessing of the headers is not nice. Why? Because the decision for a specific product/venor leads to vendor lock (see Anti Patterns) in any case.
You rely on a library. Your code will not compile if that library is not there! In the case of Qt you also rely on a little preprocessor program --- so what? If you use GTK or Win32 or MFC that don't need the preprocessor what is the difference? You cannot take your MFC program and compile it using say GTK.
The only thing you can do is to try to introduce clear layers that separate you program logic from the GUI to contain and localize the damage in case you have to go from one GUI library to another.
This is also my answer to the criticism that Qt (which was started in pre STL times if I am not completely wrong) uses non-STL containers. Separation of GUI and core program allow you to use more approprate/modern/protable technologies in the core. It is the architect's/designer's/programmer's choice where to use these non-standard constructs and how deep you will move into vendor lock.
Especially tricky in the case of Qt is that Troll Tech also offers a Qt specific abstraction layer for low-level constructs like threads/locks/sockets, etc. This means that if you are not carefull your software is locked at the top and at the bottom. If these low level services are used I would recommend to wrap them into a platform isolation layer. In the case you want to change you can replace these services using the native OS constructs or libraries like ACE, etc.
Re:licensing Qt == dangerous (Score:3, Informative)
No, it's not. All the free licenses have that. non-commercial, free, educational, etc. Check the TrollTech General FAQ [trolltech.com]
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.
Re:Cuz it's crap (examples failed when I tried the (Score:2, Informative)
I certainly wouldn't recommend you change from Qt to wxWindows... I do think Qt is technically superior to wx, but there are reasons why you might find wx more appropriate for future projects with different needs. Try installing wxPython [sourceforge.net] and have a look through the demo app - I find this a great way of showing off the features/functionality/look/feel of wxWindows to people, even if all the demo apps are written in Python. You can get a good feel for the way the same apps would look in C++ even if you don't know much about Python.
Pete.