Wrapping C constructors.

["Paul Davis" <pjdavis engineering uiowa edu>]

Hey,

I went through and changed how I was doing all of the create methods
for Goocanvas. I was having issues with a constructor and I seemed to
remember Murray saying that I should hand-code constructors as opposed
to hand-coding static create methods. Which makes quite a bit of sense
if we want the ability to subclass the goocanvas objects.

The issue at hand is this: after calling any of the goocanvas new
methods (ie, goo_canvas_rect_new(...)) we get an object that has a
ref_count of 1. This result will almost always be put into a
Glib::RefPtr. After the object is in the RefPtr, I would expect it to
have a ref_count of two. Instead, they have a ref_count of 1.

Some looking through the api has lead me to find that goocanvas always
does an unref in the new function. I'm under the impression that this
is to save C coders from calling unref on every object they create.

In C++ land this presents a predicament. We have the one new object
being referred to in two places (as a child of the parent object and
from the Glib::RefPtr) and when the RefPtr goes out of scope the
object gets destroyed. This leads to segfaults and other nasty errors.

Looking through gtkmm source, I can't find an example like this. So
almost every constructor has to be hand coded to be something along
the lines of:

Group::Group( const Glib::RefPtr<Goocanvas::Item>& parent )
 :
   ItemSimple( GOO_CANVAS_ITEM_SIMPLE(goo_canvas_group_new(
parent->gobj(), NULL ) ) )
{
 reference() ; //This is the un-good bit.
}

That seems un-good. Is there a 'gmmproc' way to autogenerate this
extra reference, or is this just a side effect of the way goocanvas is
written?

----

In other news, I've gotten the simple demo, a custom demo, and most of
the first notebook page of the 'main' demo written and working. Things
are coming along.

Paul Davis