gtkmm - GNOME with C++

Murray Cumming

Abstract

An introduction to GTK+'s C++ bindings, aimed either at newcomers or experienced GNOME developers, depending on the audience. This is just an update of the same talk given at last year's GUADEC. The advantages of gtkmm will be demonstrated. For instance, API-clarity, inheritance, encapsulation, type-safety and the use of the C++ standard library. Some gtkmm-specific techniques will be introduced. There will be brief comparisons with GTK+ and Qt, which will make gtkmm look good.

Some gnomemm libraries will be mentioned, particularly the C++ wrappers for libglade, GConf, libgnomecanvas, and gnome-vfs. Document/View with Bakery will be mentioned. The future of the gtkmm and gnomemm projects will be discussed. You will be encouraged to help.


Table of Contents

gtkmm is better
Advantages of gtkmm
Helloworld in gtkmm
Brief comparison with Qt
gtkmm-specific techniques
Glib::ustring
Glib::RefPtr<>
Signals
libglademm
Other gnomemm libraries
Further Information

gtkmm is better

Advantages of gtkmm

  1. 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.

  2. 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.

  3. 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, for users of a an API as well as the developers of the API.

  4. Member instances can be used, simplifying memory management. All GTK+ C widgets are dealt with as pointers. As a C++ coder you probably want to avoid pointers where possible.

  5. 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");
  6. C++ understands inheritance. In C, you need to know that a GtkTreeView is a GtkContainer, and cast it. C++ just knows that it is, and cast implicitly.

  7. C++ has method overloading, so 2 functions in C can be combined into one method with 2 overloads.

  8. C++ has default method arguments. So if a method should almost always take certain values, you don't need to keep writing them in your code, or wondering what they should be.

  9. There's no need to worry about GTK+'s reference-counting. Ever.

  10. Templates can make some things much simpler. Try the TreeView. You'll understand the examples in C++, but maybe not in C.

Helloworld in gtkmm


#include <gtkmm.h>

#include <iostream>



class HelloWorld : public Gtk::Window

{

public:

  HelloWorld();

  virtual ~HelloWorld();

  

protected:

  //Signal handlers:

  virtual void on_button_clicked();



  //Member widgets:

  Gtk::Button m_button;

};





HelloWorld::HelloWorld()

:  m_button("Hello World")   // A button with the label "Hello World".

{

  // Sets the border width of the window.

  set_border_width(10);

          

  // When the button receives the "clicked" signal, it will call the

  // on_button_clicked() method, defined below.

  m_button.signal_clicked().connect( SigC::slot(this, &HelloWorld::on_button_clicked) );



  // This packs the button into the Window (a container).

  add(m_button);



  // The final step is to display this newly created widget:

  m_button.show();

}



HelloWorld::~HelloWorld

{

}



void HelloWorld::on_button_clicked()

{

  std::cout << "Hello World" << std::endl;

}

 

int main (int argc, char *argv[])

{

  Gtk::Main kit(argc, argv);



  HelloWorld helloworld;

  kit.run(helloworld); //Shows the window and returns when it is closed.



  return 0;

}

Brief comparison with Qt

Qt was written when C++ was not standardised or well supported by compilers. Its design today is still based on choices available at that time, so it does not play well with more up-to-date code. Development of Qt is still closed - There is still no public development mailing list, and TrollTech have the normal corporate conservatism. As an open-source project, its design would have been improved through public debate, and it would have been possible to discard the baggage, by creating both stable and development versions.

Qt 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 it's difficult to use Qt classes with non-Qt classes. gtkmm was able to use standard C++ to provide signals without changing the C++ language. And we use Standard C++ Library containers such as std::string, std::list, std::vector and their iterators. We even provide optional STL-style interfaces to other things such as container children, allowing you to use familiar iterators and push_back(), etc with these.

With gtkmm normal C++ memory management can be used. Qt demands that all widgets are dealt with as pointers, and that you use new without using delete.

Here's a summary of those differences.

Table 1. Comparison table

 gtkmmQt
signalspure C++moc extends C++ language
containerspure C++Qt-specific containers
memory managementnormal C++ choicespointers only, and you can new, but you shouldn't delete
GNOME classesYesNo
Widget arrangementChoice of containersContainers and Layout classes are separate. Children must be added to both.
typesafe signal handlerscompile-timeruntime
LicenseLGPLGPL
DevelopmentPublicSecret

We think that gtkmm makes your code clearer and more consistent. We think it gives you less to learn and less to worry about.

Note that I could be slightly wrong about the difficulties of using delete with Qt. Someone sent me a test case last year but I lost it before having a chance to try it. At the least, I don't think there is any way to stop Qt from deleting things that you newed, and I still suspect that it causes problems to delete something that you newed yourself. I wish I hadn't lost that test case and wish I had manged to build my own quick test case with the bizarre Qt build system. Sorry, don't flame me.