What are the differences between Gtk+ and Qt?

A lot of people seem to have an opinion about which is better. I'm not really askin开发者_开发问答g for these opinions, what I'd like to know are the details: What are the things that make one graphical toolkit different from another, and which of these differences do Qt and Gtk+ have?

I can't speak directly to Gtk+, but at my previous job I used Gtkmm, and at my current job I use Qt. Both are C++, so in that regard they are consistent, but Gtkmm is/was only a wrapper to the Gtk+ code, which is in straight C.

At the time I switched jobs, I recall that one of the main differences in the Ui code was how the two toolkits handled layouts. Some parts I thought Gtk did better, some I thought Qt did better. Both let you get your widgets where you want them, eventually.

Debugging with Gtkmm was a bit of a pain, because the classes generally didn't do anything except hold a pointer to a struct and call Gtk+ functions. That extra level of indirection could be annoying.

Qt has more ancillary code that can be useful in various settings, at least compared to the version of Gtkmm that I was using. Things to make threading, inter-process communication, and networking easier are all appreciated when you need to add a new dimension to your program. They also have their containers, if you want to use those, which I think have a saner interface than the STL containers -- but they do about the same thing in the end, so it's a slight advantage.

The signal/slot mechanism between Gtkmm and Qt is different. Qt relies on an extra step in the compile process to generate meta information, which it uses for its signal/slots. An object using signals or slots must inherit from a QObject, and the QObject inheritance must be the first one, with no diamond structure. This makes it difficult to define an abstract interface that emits a signal, for example. On the plus side, they are inherently aware of threading issues, and will convert the signal/slot connection into an event-based connection when necessary. Gtkmm uses SigC signals, which are straightforward C++ classes, and to me appear to be useful in a wider variety of situations. Also, only objects that make a connection need to inherit from the magic base class, as I recall. Plus, since the slots are objects, you can use them as very nice adaptable functor objects as well.

I'm sure there are other differences, but that is what I recall now. Bear in mind my last experience with Gtkmm was about 3 years ago, so some of those items may have changed by now.

To understand the differences, its best to understand the history.

QT was developed as a UI and had some licensing issues at the beginning when KDE first started to be developed. KDE chose QT as there was not much of a selection back then (Motif, Tcl/Tk to name a few)

The GIMP was starting to be developed and at the time the Window Toolkits were not up to scratch for what the developers needed so they started to write the Gimp Tool Kit (GTK). After some time it was decided to re-write GTK and make it Object Orientated (GTK+).

Also around this time, due to the potential licensing issues with QT, Gnome was started and decided to use the GTK+ library.

Now if you look at the QT Design and the GTK Design entries on Wikipedia, you can start seeing some of the differences between the systems.

Notice that QT is referred to as a :

cross-platform application development framework

while GTK+ is referred to as a:

cross-platform widget toolkit for creating graphical user interfaces.

If these entries are to be believed then I think that is what we could the major differences between the two, but I would say its a fairly fine line in today's world.

First and foremost, you can use Gtk+ from C. Qt is C++ only.

Also, Gtk+ applications tend to have dialogs that change persistently, with a close button. Qt tends to be along the lines of Ok/Apply/Cancel. I don't know how much of this is enforced at toolkit level, though.

As for programming, I don't know what callback mechanism Gtk uses, but Qt's signals-slots mechanism absolutely rocks.