Gtk::WindowGroup is a Glib::Object derived class and should therefore have
a static create() method that returns a Glib::RefPtr<>.  Right now,
create() is missing and the default ctor is public instead.  This is
dangerous; non-Gtk::Object classes should always be instantiated in free
storage since they use pure reference counting for memory management.

Attached is a patch that adds create() and makes the default ctor
protected.  Neither change breaks ABI:  create() is only an addition, and
the linker doesn't care about public/protected/private issues.  (I'm
absolutely sure about that -- I made diffs of the nm output, and gtkmm
itself used to redeclare methods in wrap_init.cc a while ago.)

What remains are policy issues.  I'll try to outline the pros and cons:

- con: The general policy used by GTK+ as well is that no API additions are
allowed in a stable branch.  This is done to avoid binary dependencies on a
specific micro version -- people might not realize they're using a function
that didn't exist in prior micro releases.

- pro: It's argueable that adding create() should be considered as API fix
rather than API addition.  Obvious API fixes are allowed even during a
freeze (e.g. I fixed a GLib function to use gssize rather than gsize after
the official API freeze in the 1.3 series).  In our case ABI compatibility
is also required, but that's no problem.

- con: Although unlikely, people might already use Gtk::WindowGroup.  While
compiled executables will continue to work, the source won't compile
anymore due to the Gtk::WindowGroup ctor being protected.

- pro: Instantiating Gtk::WindowGroup on stack is broken anyway.  I haven't
tested it, but if it should indeed not segfault it'll at least cause a
memory leak.

Opinions?

--Daniel