Re: [Goocanvas-devel] Optional model/view rewrite
Status: Beta
Brought to you by:
dachaplin
From: Gustavo J. A. M. C. <gj...@in...> - 2006-10-11 10:23:24
|
On Ter, 2006-10-10 at 18:56 +0100, Damon Chaplin wrote: > On Tue, 2006-10-10 at 15:16 +0100, Gustavo J. A. M. Carneiro 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, > > ...) > > { > > > > > 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... > > I see from simple-demo.py you currently use something like: > > item = goocanvas.Rect(x=100, y=100, width=400, height=400, > line_width=10.0, > radius_x=20.0, > radius_y=10.0, > stroke_color="yellow", > fill_color="red") > root.add_child(item) > > Doesn't that work OK? Actually, I think it's OK. The only downside is that it is deviates a bit from the C API, which can be slightly confusing for some users. > What would the ideal python code be instead? I guess I'd rather keep the python API as it is; it is simpler and requires only the generic GObject constructor... -- Gustavo J. A. M. Carneiro <gj...@in...> <gu...@us...> The universe is always one step beyond logic. |