We’ve been working on gtkmm 3 increasingly since sometime in 2009 and today we have finally declared it stable. gtkmm 3.0.0 is out. We last did an ABI-breaking parallel-installable stable version in April 2004 for gtkmm 2.4.0 so we’ll probably have to live with this for a while.

We didn’t fullfil all our amibions, due to lack of time, but we did fix many annoyances that had built up over the years. And luckily GTK+ 3 turned out to contain far more interesting changes than initially planned, most of which are now available via gtkmm-3.0.

Personally, I’m glad that it’s done. It’s been a long hard slog over the past year, made possible by my company Openismus GmbH, just to keep up with the (nevertheless necessary) API churn during the unstable GTK+ 3 development cycle. That hasn’t left me much time for any other software development, but now I feel free.

To port to gtkmm-3.0 you should first try to build your application with gtkmm-2.4 but without using deprecated API. The deprecated API generally has documentation suggesting what new API you
should use instead. These gtkmm-3.0 porting hints might also be helpful:

Some new/changed API in gtkmm-3.0, though this list is far from complete:

Gtk:

• Adjustment is now used via RefPtr.
• AppChooser, AppChooserButton, AppChooserDialog.
• Box, ButtonBox, IconView, Paned, ProgressBar, ScaleButton, ScrollBar and Separator now derive from Orientable.
• All widgets derive from Buildable.
• Several widgets derive from Scrollable.
• CellArea and CellAreaBox
• ComboBox now derives from CellLayout.
• IconSet is now used via RefPtr.
• StyleContext, StyleProvider, and CssProvider, replacing Style and Rc.
• Grid
• NumerableIcon.
• Switch
• Widget::on_expose_event() is now Widget::on_draw().

Gdk:

• Added DeviceManager.
• Removed Drawable, Pixmap and Bitmap.
• Cursor is now used via RefPtr.
• RGBA replaces Color, though Color still exists because it is used by TextView. We hope to deprecated Color completely in gtkmm 3.2.
• Removed Colormap and its general awkardness.

General:

• Use std::vector in several methods instead of the intermediate *Handle types to make the API clearer.
• Change all operator void* to operator const void*, with a BoolExpr typede and extra documentation. This avoids an unintentional implicit cast to int, and is generally considered good practice in C++. The new C++ standard allows the use of the explicit keyword here instead, but that is not yet widespread.
• Many existing classes have many new methods.
• gtkmm-3.0 currently has no deprecated API. Not even API that was added and then deprecated during GTK+ 3.0.

See also the list of new API in gtkmm 3.0.

Thanks to everyone who helped.

We finally released glibmm 2.28.0. This is the first stable release with new API since glibmm 2.24.0 in March 2010. We skipped glibmm 2.26.0 because there was so much new and awkward API that needed to be wrapped properly for C++. It’s scary to declare so much new API stable, but we had to do it eventually.

Glib has the following new API, though this list is not complete:

• Variant: A new hierarchy of templated Variant<> types, for use with Gio::Settings and Gio::DBus.
• Regex uses a new MatchInfo class.
• build_filename() now has overloads to take up to 9 arguments,
• get_system_data_dirs() and get_system_config_dirs().

Gio has the following new API, though this list is not complete:

• Settings: For application settings, replacing GConf (or Gnome::Conf).
• DBus: API to use or implement D-Bus services.
• Proxy, ProxyAddress and ProxyResolver.
• SocketControlMessage, UnixCredentialsMessage and UnixFDMessage.

See also this list of new API in glibmm 2.28.

Gio::DBus, Glib::Variant and Gio::Settings were a huge amount of difficult work mostly by José Alburquerque, with help from Jonathon Jongsmam, Yannick Guesnet, Michael Edwards, Martin Braure de Calignon, Murray Cumming and others. Some of José Alburquerque’s work, and most of Murray Cumming’s was funded by Openismus GmbH.
Thank you, everyone.

Most Deprecated GTK+ 2 API is not in GTK+ 3

GTK+ 3 has API changes compared to GTK+ 2, but some of the new API has been added to GTK+ 2.22 and 2.24, and older API has been deprecated. gtkmm has done this too. This is intended to ease porting to GTK+ 3 (or gtkmm 3). If your application builds with GTK+ 2.24 with deprecated API disabled then it will be much easier to port to GTK+ 3 afterwards.

This requires defining C macros such as GTK_DISABLE_DEPRECATED, though you’ll want to use GDK_DISABLE_DEPRECATED, GDK_PIXBUF_DISABLE_DEPRECATED, G_DISABLE_DEPRECATED and maybe PANGO_DISABLE_DEPRECATED too. You can specify these as -D options in your Makefile.am.

However, you should not disable deprecated API in your build at all times. That just makes life unnecessarily difficult for people building from tarballs.

So over the last few years, Daniel Elstner has perfected an MM_ARG_ENABLE_WARNINGS m4 macro for use with autotools. It adds an –enable-warnings=min/max/fatal/no configure option. We use it mostly to turn on compiler-warnings-as-errors, but I think that it would be very useful to many people now during the transition to GTK+ 3.

MM_ARG_ENABLE_WARNINGS

This macro is in mm-common, which you could depend on, though it contains other stuff that is only interesting to gtkmm projects. For instance, I use it in Glom’s configure.ac file, like so:

MM_ARG_ENABLE_WARNINGS([MYPROJECT_WFLAGS],
  [-Wall],
  [-Wall -Wextra -Wno-missing-field-initializers -DGSEAL_ENABLE],
  [G GDK GDK_PIXBUF PANGO GTK])

I then use the resulting variable in my Makefile.am file, like so:

AM_CFLAGS = $(MYPROJECT_WFLAGS)

If you use non-recursive autotools (and you should) then you won’t need to repeat that much.
I also added the option to DISTCHECK_CONFIGURE_FLAGS so I am forced to fix any warnings during make distcheck, when doing a tarball release. You don’t need to do that.

Whenever I build one of these projects from git I specify –enable-warnings=fatal to autogen.sh and fix any problems that it finds. That’s why there are zero compiler warnings or use of deprecated API in Glom.

DK_ARG_ENABLE_WARNINGS

You might prefer to copy the standalone version into your project instead. There are copies of the standalone macro in various projects already. Here is an example commit that adds it to a project.

The macro call looks like this in your configure.ac, for instance:

DK_ARG_ENABLE_WARNINGS([MYPROJECT_WFLAGS],
  [-Wall -w1],
  [-pedantic -Wall -Wextra -w1],
  [G GDK GDK_PIXBUF PANGO GTK])

Since May 2010, gtkmm.org has been available in Chinese as well as English, thanks to a patch from Tao Wang. It uses DocBook XML and xml2po, like any other GNOME documentation, along with some custom DocBook XSL stylesheet parameters and our web site’s CSS.

It works. Translations can be kept up to date easily when the original English changes (though they haven’t so far in this case, admittedly) because the translations are not in copies of the documents, but in regular gettext .po files. It’s not a CMS, and editing is not particularly user-friendly, but it’s no worse than the untranslated HTML that we had previously.

I recently cleaned up the web site’s directory structure so it’s more like an application or documentation manual so you can see what I mean. And the gtkmm.org translation status is available on l10n.gnome.org thanks to Claude Paroz. The gtkmm book is also translated in the same way, so now everything other than our (Doxygen) API reference is translatable.

The build could be improved by someone who knew how. You currently need to add an HTML_generation block in the Makefile.am when you add a new locale.