Re: Goocanvas issues

[Murray Cumming <murrayc murrayc com>]

On Sat, 2007-05-19 at 18:03 -0500, Paul Davis wrote:
> Hey,
> 
> I'm running into a some new issues with these wrappings. The biggest
> roadblock right now is the wrapping of GooCanvasTable.  Its got a list
> of child properties and I'm not sure on the best way to wrap them.

I don't see any list:
http://webcvs.freedesktop.org/cairo/goocanvas/src/goocanvastable.h?view=markup


Do you mean the list in the base class?:

struct _GooCanvasGroup
{
  GooCanvasItemSimple parent_object;

  /* An array of pointers to GooCanvasItems. The first element is at the
     bottom of the display stack and the last element is at the top. */
  GPtrArray *items;
...
}

That's almost certainly a private struct field and I see no API for accessing it. 
It should probably be hidden in the C API.


If you mean the varargs for this:

GooCanvasItem*
goo_canvas_table_new (GooCanvasItem  *parent,
		      ...)
{
  GooCanvasItem *item;
  va_list var_args;
  const char *first_property;

  item = g_object_new (GOO_TYPE_CANVAS_TABLE, NULL);

  va_start (var_args, parent);
  first_property = va_arg (var_args, char*);
  if (first_property)
    g_object_set_valist (G_OBJECT (item), first_property, var_args);
  va_end (var_args);

  if (parent)
    {
      goo_canvas_item_add_child (parent, item, -1);
      g_object_unref (item);
    }

  return item;
}

you can wrap that as 
Canvas();
and 
Canvas(Item& parent);

and just let the application coder use canvas.property_*() = something.

>  I
> looked at Gtk::Table and its implementation. It uses a
> Table_Helpers::Child class that contains the child-properties

It provides access to the children, but not to the child properties, I
think. Let's ignore the child properties unless we find they are
necessary.

It would be nice to have generic child property support for other gtkmm
containers.

>  and
> allows for STL-Container like access to the children. This Child uses
> a GtkTableChild object thing that I don't think exists for the
> GooCanvasTable equivalent.
> 
> Any help or ideas on how to wrap that object would be most welcome.
> 
> I've found a bit of a bug when using
> Goocanvas::Canvas::get_root_item().  The Glib::RefPtr< Goocanvas::Item
> > object thats returned contains an GooCanvasItem thats only ref'ed
> once. So when the RefPtr goes out of scope, the root item dies, which
> causes a segfault internally in GooCanvas.

Yes, you usually need to use the refreturn option on get methods, with
_WRAP_METHOD. I have done that now in the libgoocanvasmm svn.

> I think  I've verified this, becuase if I store the root item's RefPtr
> as a class member ( so it doesn't get destroyed till the end of the
> program ) the segfault disappears and when the program exits, there's
> an error about g_object_unref fails the G_IS_OBJECT( object ) test (
> Which I'm assuming means it got destroyed by one or the other and the
> second destruction is failing.
> 
> So basically, I need to add a ref operation somewhere, but I'm
> uncertain as to where this should happen.
> 
> In other news, quite a bit of the GooCanvas API has been wrapped. I'm
> starting to work on getting the examples up and going.

Thanks for this. Please keep mentioning stuff that you get stuck on,
trying to be precise about what part of the API it is.

-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com