Abstract
There will be two parts.
The first part will be an introduction to GTK+'s C++ bindings for newcomers. The advantages of gtkmmm will be demonstrated with simple examples. For instance, API-clarity, inheritance, encapsulation, type-safety, and use of the C++ standard library. There will be a brief comparison with QT.
The second part will detail the most important differences between gtkmm 1.2 and the new gtkmm 2.0, for those who already use gtkmm. For instance, the new RefPtr for reference-counted resources, the new UTF8 string class, the signal accessors, properties, the new main window concept.
Table of Contents
TODO: This is an early draft - It needs some filling out, and maybe some thinning out.
will be demonstrated with simple examples. For instance, API-clarity, inheritance, encapsulation, type-safety, and use of the C++ standard library.
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.
#include <gtkmm/button.h>
#include <gtkmm/main.h>
#include <gtkmm/window.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") // creates a new 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
// hello() method. The hello() method is 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;
}
QT originates from a time when C++ was not standardised or well supported by compilers. Its design today is still based upon the choices available at that time, so it does not play well with more up-to-date code. Development of QT is still effectively 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 jettison the baggage.
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 of Standard C++ Library containers such as std::string, std::list, std::vector and their iterators. We even provide STL-style interfaces to other things such as container children, allowing you to use 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 deletion of widgets is surrendered to parent widgets.
Here's a summary of those differences.
Table 1. Comparison table
| gtkmm | QT | |
|---|---|---|
| signals | pure C++ | moc extends C++ language |
| containers | pure C++ | QT-specific containers |
| memory management | normal C++ choices | pointers only, and you can new, but you shouldn't delete |
| GNOME classes | Yes | No |
| Widget arrangement | Choice of containers | Containers and Layout classes are separate. Children must be added to both. |