gtkmm Frequently Asked Questions

Abstract

Here are some frequently-asked questions and answers about gtkmm. If your questions aren't answered here then please email the gtkmm mailing list. If you would like to add to this FAQ, then please patch this file (gtkmm-faq.xml) or just send your suggestion to the mailing list.

1. gtkmm's place in the world.

1.1. What is GTK+?
1.2. What is gtkmm (Previously known as Gtk--)?
1.3. Why is it named gtkmm?
1.4. Why use gtkmm instead of GTK+?
1.5. Why use libsigc++? Why not just use the regular GTK+ signal functions?
1.6. Why isn't GTK+/GNOME itself written in C++.
1.7. Why not just use Qt if you like C++ so much?
1.8. What about Inti or gcode?

2. How good is gtkmm?

2.1. What systems does it run under?
2.2. How complete is it?
2.3. Does gtkmm support all the C++ goodies like inheritance, polymorphism, etc?
2.4. Does gtkmm use Standard C++ (STL) containers such as std::string and std::list
2.5. Does gtkmm force STL-style interfaces onto GTK+ widgets in a way that is inappropriate, difficult, or badly-implemented?
2.6. Does the gtkmm API use C types, such as structs?
2.7. What applications have been written in gtkmm?
2.8. How does gtkmm compare to Qt?
2.9. Have you wrapped all of the GNOME APIs as well as GTK+?
2.10. Is gtkmm "bloated"

3. Further information

3.1. Is there a gtkmm mailing list?
3.2. What documentation is there for gtkmm?
3.3. Where can I find some example code?

4. Using gtkmm

4.1. What compiler arguments should I use to compile a gtkmm program?
4.2. My application complains that it can't find libgtkmm.so
4.3. How can I build a static executable?
4.4. How can I get the GTK+ object from a gtkmm object?
4.5. How can I wrap a GTK+ widget in a gtkmm instance?
4.6. Can I use C++ exceptions with gtkmm?
4.7. How can I use Glade and/or libglade with gtkmm?
4.8. What does Gtk::manage(widget) do?
4.9. How can I learn about arranging widgets? I am confused by the packing options
4.10. I'm used to MFC. Where's the Document and the View? or How do I use the Document/View idea? or How do I use the MVC pattern?
4.11. How do I load pixmaps for use with gtkmm?
4.12. Is gtkmm thread-safe?
4.13. Why does my application seem to segfault inside a dynamic_cast<> in gtkmm?

1. gtkmm's place in the world.
1.1. What is GTK+? 1.2. What is gtkmm (Previously known as Gtk--)? 1.3. Why is it named gtkmm? 1.4. Why use gtkmm instead of GTK+? 1.5. Why use libsigc++? Why not just use the regular GTK+ signal functions? 1.6. Why isn't GTK+/GNOME itself written in C++. 1.7. Why not just use Qt if you like C++ so much? 1.8. What about Inti or gcode?
1.1.	What is GTK+?
	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.
1.2.	What is gtkmm (Previously known as Gtk--)?
	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.
1.3.	Why is it named gtkmm?
	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.
1.4.	Why use gtkmm instead of GTK+?
	gtkmm allows you to write code using normal C++ techniques such as encapsulation, derivation, and polymorphism. As a C++ programmer you probably already realise that this leads to clearer and better organised code. gtkmm is more type-safe, so the compiler can detect errors that would only be detected at run time when using C. This use of specific types also makes the API clearer because you can see what types should be used just by looking at a method's declaration. Inheritance can be used to derive new widgets. The derivation of new widgets in GTK+ C code is so complicated and error prone that almost no C coders do it. As a C++ developer you know that derivation is an essential Object Orientated technique. Member instances can be used, simplifying memory management. All GTK+ C widgets are dealt with by use of pointers. As a C++ coder you know that pointers should be avoided where possible. Less code. The GTK+ C object model uses prefixed function names and cast macros. For instance: gtk_button_set_text(GTK_BUTTON(button), "sometext"); gtkmm C++ code is shorter and clearer. For instance: button.set_text("sometext"); There's no need to worry about GTK+'s inconsistent reference-counting policy.
1.5.	Why use libsigc++? Why not just use the regular GTK+ signal functions?
	GTK+ signals aren't typesafe, so the compiler can't tell you whether your callback has the wrong number or type of arguments or return value. They can only be used with functions or static methods. With libsigc++ callbacks can also be instance methods, using the member data of a particular object. They can also be virtual methods which you could override in a derived class.
1.6.	Why isn't GTK+/GNOME itself written in C++.
	C is a simpler language so more people are familiar with it, particularly on Unix. C can be wrapped by any other language, making the API available to more developers. GTK+ and GNOME have very well organised C code, much more sane than most of the gnarly C code that we encounter. This is partly due to it's C-based object-orientated structure.
1.7.	Why not just use Qt if you like C++ so much?
	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.
1.8.	What about Inti or gcode?
	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.
2. How good is gtkmm?
2.1. What systems does it run under? 2.2. How complete is it? 2.3. Does gtkmm support all the C++ goodies like inheritance, polymorphism, etc? 2.4. Does gtkmm use Standard C++ (STL) containers such as std::string and std::list 2.5. Does gtkmm force STL-style interfaces onto GTK+ widgets in a way that is inappropriate, difficult, or badly-implemented? 2.6. Does the gtkmm API use C types, such as structs? 2.7. What applications have been written in gtkmm? 2.8. How does gtkmm compare to Qt? 2.9. Have you wrapped all of the GNOME APIs as well as GTK+? 2.10. Is gtkmm "bloated"
2.1.	What systems does it run under?
	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: Sun's Forte C++, on Solaris. Windows, with the mingw build tools.
2.2.	How complete is it?
	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.
2.3.	Does gtkmm support all the C++ goodies like inheritance, polymorphism, etc?
	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.
2.4.	Does gtkmm use Standard C++ (STL) containers such as std::string and std::list
	Yes, we believe in reusing standard C++ code wherever possible. This might not be obvious at first because: gtkmm has Glib::ustring which has almost the same interface as std::string. This new type exists because the C++ standard does not support UTF8-encoded strings. The gtkmm API uses types such as Glib::ListHandle<int> which can be assigned to almost any standard C++ container, such as std::list or std::vector. These intermediate types have been used instead of forcing you to use any particular container. 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.
2.5.	Does gtkmm force STL-style interfaces onto GTK+ widgets in a way that is inappropriate, difficult, or badly-implemented?
	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++.
2.6.	Does the gtkmm API use C types, such as structs?
	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.
2.7.	What applications have been written in gtkmm?
	Check out the list of applications on the Additional Resources page from the gtkmm site.
2.8.	How does gtkmm compare to Qt?
	gtkmm uses pure C++. Qt requires extensions to C++ that are parsed by the moc pre-processor. gtkmm uses std::string, std::list, std::vector, iterators, etc. Qt has it's own Qt-specific containers. With gtkmm normal C++ memory management can be used. Qt demands that all widgets are dealt with as pointers, and that deletion of widgets is surrendered to parent widgets. Arrangement of widgets seems to be simpler in gtkmm. In Qt, Containers and Layouts are separate classes, and child widgets must be added to both. The gtkmm API tends to be more explicit. The behaviour of Qt classes is often dependent upon the implicit effects of confusingly-overridden constructors.
2.9.	Have you wrapped all of the GNOME APIs as well as GTK+?
	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.
2.10.	Is gtkmm "bloated"
	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 It contains lots of generated HTML documentation - the reference documentation, the book, and this FAQ, for instance. It also contains the Docbook XML sources for that documentation. It contains the .hg/.ccg source files used to generate the .h/.cc C++ source files, as well as those generated files. We ship these generated files to reduce the dependencies needed to build gtkmm itself, to make your life easier.
3. Further information
3.1. Is there a gtkmm mailing list? 3.2. What documentation is there for gtkmm? 3.3. Where can I find some example code?
3.1.	Is there a gtkmm mailing list?
	Yes. See the subscription page
3.2.	What documentation is there for gtkmm?
	There is a largely complete tutorial, automatically-generated reference documentation, this faq, and a wealth of running examples available at the documentation page
3.3.	Where can I find some example code?
	See the examples directory in the gtkmm distribution. There are also several large third-party applications whose source you can examine.
4. Using gtkmm
4.1. What compiler arguments should I use to compile a gtkmm program? 4.2. My application complains that it can't find libgtkmm.so 4.3. How can I build a static executable? 4.4. How can I get the GTK+ object from a gtkmm object? 4.5. How can I wrap a GTK+ widget in a gtkmm instance? 4.6. Can I use C++ exceptions with gtkmm? 4.7. How can I use Glade and/or libglade with gtkmm? 4.8. What does Gtk::manage(widget) do? 4.9. How can I learn about arranging widgets? I am confused by the packing options 4.10. I'm used to MFC. Where's the Document and the View? or How do I use the Document/View idea? or How do I use the MVC pattern? 4.11. How do I load pixmaps for use with gtkmm? 4.12. Is gtkmm thread-safe? 4.13. Why does my application seem to segfault inside a dynamic_cast<> in gtkmm?
4.1.	What compiler arguments should I use to compile a gtkmm program?
	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.
4.2.	My application complains that it can't find libgtkmm.so
	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
4.3.	How can I build a static executable?
	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
4.4.	How can I get the GTK+ object from a gtkmm object?
	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.
4.5.	How can I wrap a GTK+ widget in a gtkmm instance?
	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.
4.6.	Can I use C++ exceptions with gtkmm?
	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.
4.7.	How can I use Glade and/or libglade with gtkmm?
	Use libglademm, which is part of gnomemm and wraps libglade. It allows you to load widget information from the XML user interface description files that Glade generates at runtime. This method is strongly recommended. Experience has shown that it works well for large projects, and there is a lot of example code out there you can look at. For an introduction, see the corresponding chapter in the gtkmm tutorial. Alternatively, Glade 2 can output C++ code instead of C code, when using Glade--, which is not part of gnomemm. Note that code generation is a deprecated feature in Glade 3. For questions regarding Glade--, please use its own mailing list.
4.8.	What does Gtk::manage(widget) do?
	- 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.
4.9.	How can I learn about arranging widgets? I am confused by the packing options
	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.
4.10.	I'm used to MFC. Where's the Document and the View? or How do I use the Document/View idea? or How do I use the MVC pattern?
	Document/View (which is a useful version of MVC) is not supported directly by GTK+, though it is commonly used by GTK+ programmers. However, the TextView and TreeView interfaces are split up into model and view. The Bakery library makes it very easy for gtkmm/gnomemm C++ coders to use the Document/View framework.
4.11.	How do I load pixmaps for use with gtkmm?
	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.
4.12.	Is gtkmm thread-safe?
	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.
4.13.	Why does my application seem to segfault inside a dynamic_cast<> in gtkmm?
	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.