Re: Canvas shortcomings



Hello!

Sorry for digging that up...

On 22 Jun 2001 15:26:29 +0200, Soeren Sandmann wrote:
> Lauris Kaplinski <lauris ximian com> writes:
> > struct _Node {
> >   Base_Object base_object;
> >   Node *parent;
> >   Node *next;
> > }
> > 
> > struct _NodeClass {
> >   Base_Class base_class;
> >   void (* add_child) (Node *node, Node *child, Node *insertafter);
> >   void (* remove_child) (Node *node, Node *child);
> > }
> > 
> > So you can derive new grouping objects from any non-grouping one by 
> > implementing virtual methods.
> 
> This means that calls to add/remove_child can't be type checked.  The
> compiler has no way of knowing whether add/remove_child is actually
> implemented by the object called.  
> 
> I don't think it is a good idea to export something like that in a
> Bonobo interface.  There is no problems doing in the C implementation,
> of course.

You are right. The only typechecking is runtime. But I cannot see that 
as problem anyways.
Take an example:

gtk_container_add (GTK_CONTAINER (widget), child)

Is used extensively, and usually errors are caught quickly.

Whether given CanvasItem accepts children should be determined by 
application anyways. Just like in current framework there is no way for 
compiler to determine, whether given item is subclass of group or not.
So unless you are using plain groups, you are exactly at the same
situation.

One good thing would be to add return value:

gboolean gnome_canvas_item_add_child (...)

So TRUE means, that child is accepted. Plus you get the extra benefit,
that item implementations can restrict, which children types they can
have.

Just my ideas,
Lauris Kaplinski






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]