I didn’t get around to blogging about gtkmm 3.8 when I released it last month, partly because we had to fix a crasher bug and do a gtkmm .1 release before people noticed.
Anyway, just a little while after GNOME 3.8 was released, we managed to release gtkmm 3.8 and glibmm 2.36. There is quite a bit of work in these, almost all by José Alburquerque and Kjell Ahlstedt, as well as the usual few days of last-minute work by me to wrap remaining new API.
I spend very little time on glibmm and gtkmm these days, and don’t have much motivation to change that.
There’s also a change that we expect in glib 2.38 that will break many installed applications that use gtkmm. We successfully begged the glib developers to add a special case for us in glib 2.36, but we have not found any way to avoid this for 2.38. So far our best option seems to be to do a new parallel-installed gtkmm (and glibmm) ABI, leaving the old (broken with glib 2.38) one behind, at least allowing applications to be changed slightly and then rebuilt.
Personally, I have no great incentive to go through that pain.
Sad news about legacy gtkmm custom classes getting broken by glib change. Does PyGTK face similar challenges?
If the first instance call is made lazy and really calls the glib instantiation after interfaces have been added, that could workaround editing sources and just require a re-compile couldn’t it?