What Should I Choose: Gtk+ or Qt

What should I choose: GTK+ or Qt?

As you seem to primarily target Linux, then the choice mostly depends on the programming language you want to use.

If you code in C, then obviously go for GTK+

If you code in C++, go for Qt, otherwise you will need Gtkmm (a C++ wrapper over GTK+)

If you code in Python, both GTK+ and Qt have bindings for the language: see PyGtk, PyQt and PySide (the one launched by Nokia themselves).

If you code in Java, Qt is no more a viable option imho as Nokia discontinued Qt Jambi (the Java bindings for Qt).

Also, Qt is more top-notch regarding its scenegraph QGraphicsScene API, its scripting engine built over Javascript Core (the engine powering WebKit), its state machine and animations framework, and the declarative UI.

GTK+ doesn't offer that much although you can use Clutter alongside with it.

If you're specifically looking into DB, XML (GTK+ has a parser for a subset of XML) and threading (GTK+ has GLib) features then Qt will offer all that in QtSql, QtXml and QtConcurrent.

All in all, I would say Qt is a sure choice. But GTK+ is very capable as well.

I'm not sure you will get a crystal clear answer for your question, which explains why some people keep preferring Gnome over KDE or vice-versa. Choose what works best for you.

PS: I you plan to also target Symbian, then go for Qt.

EDIT: Something that is also great with Qt is QtWebView: it brings Chromium into your Qt application to display web content. Others are embedding web content into their application using for instance Awesomium or Berkelium.

What are the differences between Gtk+ and Qt?

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.

How do GTK and Qt integrate with Linux in comparison to how they integrate with Windows and OS X?

On Linux (desktops and laptops) the graphical screen is generally displayed (at least that was the case in beginning of 2015) by the X11 server. Your GUI app is communicating with that server thru sockets, often locally on a Unix socket like /tmp/.X11-unix/X0. The X11 server is generally Xorg.

^{For some embedded devices like Android mobile phones or some gadgets (GPS in cars, automotive or medical device industry) it is different (DirectFB, framebuffer devices -which is used by the X11 server on your desktop, ...)}

Some distributions are switching to Wayland (or perhaps to Mir). Since I don't know these much, I cannot explain the gory details. AFAIU, there is still some server involved (which, like Xorg, is the only user-land software component talking to your graphics card) and some protocol, and major toolkits like Qt & GTK are been adapted to them (so if you code for Qt or for GTK, you don't care about those details, but you should upgrade your toolkit).

The graphical toolkits (Qt, Gtk) are interacting with the X11 server (or the Wayland one) thru some specific protocol(s), e.g. X Window System protocols for X11. For historical reasons, these protocols are quite complex, and practically require to follow some conventions like EWMH.

See also this answer to a related question. I explain there that X11 is not used today as it was in the previous century; in particular the server-side drawing abilities of X11 (e.g. Xlib's XDrawLine or XDrawText) are rarely used today, because the toolkit is drawing a pixmap image client side and sending it to the server.

Notice that you might consider giving not a GUI interface, but a Web interface, to your application (e.g. using libraries like libonion, Wt, ....); then your application becomes a specialized Web server, and the user would go thru his browser (in his desktop/laptop/tablet/phone) to interact with your app.

Practically speaking, user interfaces are so complex that you really should use some toolkit for them (Qt if coding in C++). Coding from scratch (even above Xlib or XCB for X11) would requires years of work.

There exist several other widget toolkits above X11, e.g. FOX toolkit, FLTK (but most of them have much less features than Qt or GTK).

What are the differences between the OpenGL, GTK and QT libraries?

OpenGL is a library for drawing graphics on a low level. It excels mainly at 3D graphics. The most important competitor to OpenGL is Direct3D (not the whole DirectX).

GL is only really powerful if you have it hardware accelerated. Today, almost every desktop or laptop solution has GL acceleration, but on some systems where the graphics card is integrated into the chipset, it is still rather slow.

For day-by-day hacking, GL can serve many unusual purposes. The reason is that you can leverage the GPU's processing power for graphic related tasks. For anything non-graphical, newer languages like CUDA exist as well to access the GPU.

While GL's real strengths lie in 3D scene rendering, it is often also used for 2D manipulation or composition. The reason is that 2D acceleration architectures of graphics cards often don't reach the power (freedom) or performance of GL. That's why sometimes GL is used for video output (mainly scaling) or blending tasks, even if specific 2D acceleration for these tasks would be available. Mac OS X is a prominent example of a whole desktop (optionally) being rendered through GL to allow appealing effects without high CPU load. But it can also be used for example to blend anti-aliased text glyphs onto a textured background.

As soon as you do a graphical, performance critical task, you will probably want the GPU to help out (possible even if you don't draw on screen) and then OpenGL is the clean, standardized, cross-platform answer to your needs. Today's GUI toolkits mostly don't offer you GPU-accelerated drawing, but the inclusion of GL rendering into their widgets. So you can use them for UI drawing and include your performance critical realtime graphics where it suits. Building a whole UI inside GL is a pain, but there are also solutions for that available (typical use cases are games with in-game UI).

Differences that matter between GTK+ and QT?

Note: I'm probably biased towards Qt as I never used GTK seriously.

• Qt's graphics view and scene system is awesome, GTK only has low level Cairo.
• Writing custom widgets seems easier with Qt, probably because of the OO design. I don't know which API has more "advanced" widgets, but the basic ones are probably enough for most applications with a little bit of customization.
• If you want a completely custom display for your app with special effects and all, you can easily write one based on graphics view/scene. Qt 4.7 also adds Qt Quick to design fancy interfaces, I didn't have the opportunity to test it yet but it looks pretty cool.

Overall I think both are great frameworks and offer enough for any application, but with Qt you get everything in a nice package, when you have to use 3rd party additions or reinvent the wheel to get the same job done with GTK.

Your best library for create GUI ( gtk, qt, win32 api, etc )?

Let's see.

• Win32 is very low-level, C based, and awkward to use.
• MFC is considered obsolete.
• C# (or C++) with .NET is probably your primary choice for Windows-specific development.
• • There are even semi-limited ways to port that code to other platforms (Mono).
• Java is great for very platform-independent code that "just runs". Sorry, you said C++.
• QT is relatively platform-independent.
• GTK+, of course, although I personally don't have much experience with it.

Personally, if I do something Windows-specific, I use .NET - the tools in Visual Studio are very powerful, and it's a great all-encompassing suite.

For platform-independent stuff, I use Java, but that may not be your tool of choice. I've seen QT used a lot for that purpose.

Should a person new to windowed applications study X, GTK+, or what?

Pure X is quite hardcore these days, and not very portable. Basically, there are three major toolkits:

• GTK+ (and C++ wrapper GTKmm)
• Qt
• wxWidgets

which are pretty comparable, so which to choose is a matter of taste. All three run on major three operating systems, although GTK+ on Mac and Windows is little bit awkward.

RInside with Qt, GTK+ or Tcl

I can only speak for the Qt bindings which I have worked on, and which are documented via
the following:

• an entire examples subdirectory of the sources / installed package devoted to this]

• blog posts about this several times which comes up as the first Google hit for 'RInside Qt'; similarly for several of my presentations which featured this

• the entire chapter 9 in my Rcpp book

You can probably work something out for Tcl/Tk and Gtk -- but given that RInside and Rcpp are C++ based, Qt seemed like a natural fit.

---

Related Topics