GTK+ is the GUI widget toolkit, written in C, which serves as the foundation for the GNOME project as well as many stand-alone applications. GTK+ is the foundation on which gtkmm is built. See http://www.gtk.org.

gtkmm is a C++ wrapper for GTK+. That is, it is a language binding that lets you use GTK+ from C++. This includes support for C++ features such as inheritance, polymorphism and other powerful techniques which C++ programmers expect to have at their disposal.

gtkmm was orignally named gtk-- because GTK+ already has a + in the name. However, as -- is not easily indexed by search engines the package generally went by the name gtkmm, and that's what we stuck with.

gtkmm developers tend to prefer gtkmm to Qt because gtkmm does things in a more C++ way. Qt originates from a time when C++ and the standard library were not standardised or well supported by compilers. It therefore duplicates a lot of stuff that is now in the standard library, such as containers and type information. Most significantly, they modified the C++ language to provide signals, so that Qt classes can not be used easily with non-Qt classes. gtkmm was able to use standard C++ to provide signals without changing the C++ language.

Also, gtkmm and gnomemm allow you to build software which works more closely with the GNOME desktop.

Inti was a RedHat project which aimed to create a monolothic C++ programming framework palatable to corporate customers, and which could be led by RedHat. Among other things, it was intended to include a GTK+ binding for C++. That binding was to be similar, but less versatile, than gtkmm. Inti did not release any code, though some existed in CVS. That project was discontinued see here. The Inti name has now been adopted by the previously-named gcode project.

GCode/Inti seems to have inherited some of the original Inti's code while also tracking gtkmm. As far as we can tell, the only difference is that GCode uses less C++ techniques, preferring to expose more of the GTK+ C API. At the present time, the gcode/inti FAQ makes false suggestions about gtkmm - See the questions about STL-style iterfaces and C types. Also, gcode/inti forces the use of a memory management system that is equivalent to gtkmm's optional Gtk::manage() feature. It does not allow the complete range of normal C++ memory management techniques.

We don't know why the author chose to start a separate and secret project instead of helping the gtkmm community.

gtkmm should run under any UNIX-type system with the proper compilers and libraries installed. The GNU C++ compiler (g++, part of gcc) together with the GNU toolset (such as found on Linux and *BSD systems) comprise its default build environment.

gtkmm can also be be built and used with:

gtkmm tries to offer all of the functionality offered by GTK+. This means that you should be able to do anything with gtkmm that's supported by GTK+, and do it more easily. If something isn't covered then we want to know about it.

Yes. gtkmm objects are normal C++ objects which implement the GTK+ inheritance model through C++ inheritance. You can do with the gtkmm widgets everything that you can do with any other C++ class.

Yes, we believe in reusing standard C++ code wherever possible. This might not be obvious at first because:

In addition, some widgets, such as Gtk::TreeView, have interfaces which are very similar to the standard containers. For instance, you can iterate through the selected rows.

No, we do not force you. We have provided STL-style interfaces for some container widgets, to allow you to iterate over the child widgets, but these are in addition the the simpler interfaces. We have done this because we believe that STL-style interfaces sometimes require too much code to perform simple tasks. On the other hand, some people religiously prefer STL-code wherever possible. You have the choice.

These STL-interfaces are implemented with quite simple code and have been found to work without problems. There are no known bugs, as you can see on the bugs page.

Some classes such as Gtk::TextBuffer have only an STL-style interface. This is because the underlying widget has an STL-style interface, implemented in C. So this is the most appropriate, and easiest, way to wrap that API in C++.

No, we wrap almost all parameters as C++ classes. which use C++ memory management. If you find parameters that use C types without good reason then we want to know about it.

Check out the list of applications on the Additional Resources page from the gtkmm site.

We have wrapped gnome-libs, in gnomemm, which provides the additional GNOME functionality. Some parts, such as the gnome-vfs, and Bonobo wrappers are not yet mature.

No, gtkmm is a thin wrapper. People might be surprised at the large size of the gtkmm source tarball. The gtkmm tarball is large because

We ship these generated files to reduce the dependencies needed to build gtkmm itself, to make your life easier.

Yes. See the subscription page

There is a largely complete tutorial, automatically-generated reference documentation, this faq, and a wealth of running examples available at the documentation page

See the examples directory in the gtkmm distribution. There are also several large third-party applications whose source you can examine.

For gtkmm 2, you should use pkg-config. For instance, for gtkmm 2.0/2.2:

pkg-config gtkmm-2.0 --libs --cflags

Or for gtkmm 2.4, wich installs in parallel with gtkmm 2.0/2.2:

pkg-config gtkmm-2.4 --libs --cflags

You should use pkg-config's PKG_CHECK_MODULES macro in your configure.in file, as demonstrated in the gtkmm_hello package.

Since this is the single most asked question about running GTK+ programs, we'll answer it here, even though it is in the GTK+ FAQ. Make sure the /usr/local/lib (the default install dir for gtkmm) is properly configured in your /etc/ldconf or that it is in your LD_LIBRARY_PATH environment variable.

Alternatively, specify another prefix when running configure. For instance, on RedHat, you should do this: ./configure --prefix=/usr

gtkmm is pre-installed on most linux distributions so you don't really need to, but you can reconfigure gtkmm like so:

./configure --enable-static

make

make install

If you need some GTK+ functionality which is not supported through gtkmm, you can call Gtk::Widget::gobj() (gtkobj() in gtkmm version 1.x) which will return a pointer to the plain C GTK+ data structure. You can then operate directly on this C object as you would in any GTK+ program.

Glib::wrap() will give you a pointer to gtkmm object. It is an overloaded function, so it will give you an instance of the appropriate class.

Yes, it is possible but it is not a very good idea. The official answer is that, since plain C doesn't know what a C++ exception is, you can use exceptions in your gtkmm code as long as there are no C functions in your call stack between the thrower and the catcher. This means that you have to catch your exception locally.

You will be warned at runtime about uncaught exceptions, and you can specify a different handler for uncaught exceptions. Some gtkmm methods do even use exceptions to report errors. The exceptions types that might be thrown are listed in the reference documentation of these methods.

- This means 'The container widget will delete this widget.' Some people prefer to use it so that they don't need to worry about when to delete their widgets. Gtk::manage() should only be used when add()ing a widget to a container widget.

Glade is a great way to see what can be done with GTK+ and GNOME widgets. Use Glade to explore the choice of widgets and to see how they can be put together. You should then be able to use the same settings as arguments to your widget constructors, and to the add() and pack() method. Or you could us libglademm to load the GUI at runtime.

Use Gdk::Pixbuf and/or Gtk::Image. Both are easy to use and support a wide range of image file types via pixbuf loader plugins.

Paul Davis wrote:

Neither X, nor GDK nor GTK+ nor gtkmm are thread safe by themselves. You must use either the gdk_threads_{enter,leave}() functions to protect any and every call to GDK/GTK+/gtkmm functions, or alternatively, ensure that only a single thread makes such calls. One common way to do this is to have non-GUI threads send requests to the GUI thread via a pipe. The pipe is hooked into the main glib event loop used by GTK.

Personally, i have always used the single-threaded approach, which I find much more suitable for my apps.

Note that glibmm comes with Glib::Dispatcher, which implements a cross-thread signal using the pipe approach described above.

Andreas Rottmann added:

If you need a more sophisticated cross-thread message-passing approach, take a look at libsigc++ extras. It provides cross-thread, typesafe slot invocation on top of libsigc++ and comes with a gtkmm example.

gcc 2.96 and earlier have a bug which prevents use of dynamic_cast<> during a constructor. This is only a problem when you derive a new class from a gtkmm class and specify a specific base class constructor. You can avoid this by using a different constructor. For instance, instead of using the Gtk::Button("sometext") constructor, you could use the default constructor and then call Gtk::Button::set_label(). See this bug report for more information. This bug does not apply to all non-default constructors - if you are using an old compiler then you should just try it and see.