gtkmm-specific techniques

Glib::ustring

glib::ustring has much the same interface as std::string, but contains UTF8 strings. Note that a normal ANSI string is also a UTF8 string, so, if you want to, you can use this class without every thinking about UTF8.

Also, this class has conversions to and from std::string, so you can use a std::string instead of a glib::ustring - However, operations on individual characters would not work with multi-byte translations, just as normal pointer arithmetic on a C char* wouldn't work.

In a perfect world the C++ Standard Library would contain a a UTF8 string, but it doesn't.

Glib::RefPtr<>

GObject is a bit stricter than GtkObject about how we can manage its memory. We can only unref() a GObject, we can never destroy it. Therefore our C++ wrapper (which is used by the C GObject) must remain alive as long as the C instance. But of course it should be deleted when glib tells us that the C instance has died.

Of course you don't want to worry about all that, so we've created the RefPtr<> smartpointer which does all that for you. Objects such as Gdk::Bitmap can now only be instantiated with a create() function. For instance,


Glib::RefPtr<Gdk::Bitmap> bitmap = Gdk::Bitmap::create(window, data, width, height);

You have no way of getting a bare Gdk::Bitmap. bitmap is then a smart pointer, so you can do this, much like a normal pointer:


if(bitmap)

{

  int depth = bitmap->get_depth().

}

When bitmap goes out of scope an unref() will happen in the background and you don't need to worry about it anymore.

This should mean that you *never* need to ref()/unref() a GDK object again. GTK+ is a little inconsistent about its refcounting, though there are a loose set of rules. All gtkmm methods do any extra referencing for you, so you don't need to worry about that.

Signals

signals are prefixed by signal_, and accessible via accessors. For instance,

 button.signal_clicked().connect( SigC::slot(*this, &Something::somemethod) );