The varargs lists also add a bit of confusion to the C++ constructors too.  Although, for C++ my original idea was to go through and add extra hand-coded constructors for the extra arguments.

As to the parent, I was going to make an extra set of constructors that didn't require a parent.  As passing a Glib::RefPtr<GooCanvas::Item>() to indicate no parent seems rather silly.

Anyway, I'll take a look at the new format later this afternoon.  >From what I've read it looks like it could reall make things interesting.

Paul

On 10/10/06, Gustavo J. A. M. Carneiro <gjc@inescporto.pt> wrote:
On Ter, 2006-10-10 at 14:24 +0100, Damon Chaplin wrote:
[...]
>  o I've standardized the item creation functions so they all take a
>    parent item, any required specific arguments, then pairs of
>    object properties.

The current constructor for GooCanvasEllipse looks like this:

GooCanvasItem*
goo_canvas_ellipse_new (GooCanvasItem *parent,
                        gdouble        center_x,
                        gdouble        center_y,
                        gdouble        radius_x,
                        gdouble        radius_y,
                        ...)
{
  GooCanvasItem *item;
  GooCanvasEllipse *ellipse;
  GooCanvasEllipseData *ellipse_data;
  const char *first_property;
  va_list var_args;

  item = g_object_new (GOO_TYPE_CANVAS_ELLIPSE, NULL);
  ellipse = (GooCanvasEllipse*) item;

  ellipse_data = ellipse->ellipse_data;
  ellipse_data->center_x = center_x;
  ellipse_data->center_y = center_y;
  ellipse_data->radius_x = radius_x;
  ellipse_data->radius_y = radius_y;

  va_start (var_args, radius_y);
  first_property = va_arg (var_args, char*);
  if (first_property)
    g_object_set_valist ((GObject*) 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;
}

  From the point of view of Python language bindings this type of
constructor poses some problems for subclassing.  The problem is briefly
described in [1].  Basically, we need all constructor parameters to
exist also as GObject properties.  In the particular case, all
constructor parameters in GooCanvasEllipse are also available as GObject
properties, except "parent".  In GooCanvasItems in general a "parent"
property is missed.  Even Gtk widges have a "parent" property, so I
don't think this is some crazy idea...

  Cheers.

[1]
http://live.gnome.org/PyGTK/WhatsNew28#head-9086d011479cb9c977b3e0f5da0aa5bc38ff72bb

--
Gustavo J. A. M. Carneiro
<gjc@inescporto.pt> < gustavo@users.sourceforge.net>
The universe is always one step beyond logic.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Goocanvas-devel mailing list
Goocanvas-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/goocanvas-devel