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, this will not work with multi-byte translations, just as normal C char* code wouldn't.

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

In gtkmm 1.2 you had to worry about the Window's delete_event signal to make your application quit properly. If you didn't or if you got it wrong then your Window would self-destruct and cause a segfault. This was tedious and difficult, and nobody really understood it.

We've made life simpler by preventing Window from self-destructing, and adding the Gtk::Main::run(window) override. It shows the window, starts the event loop, and stops the event loop when the window is closed. You can think of it as a way to say 'This is the main application window.' or 'The window and the application have the same lifetime.'

Most of the GDK objects are now based on GObject, so we now have auto-generated classes for them. However, 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 it's 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 are now prefixed by signal_, and accessible via accessors. For instance,

gtkmm 1.2:

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

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

GTK+ properties can be used like so:

someobject.property_something().set_value(2);

int value = someobject.property_something().get_value();

Properties are rarely used, but they do seem to be necessary for Gtk::TextView.