Re: [GNOME] GnomeCanvas interface

[Federico Mena Quintero <federico nuclecu unam mx>]

>  There needs to be some sort of gnome_canvas_item_configure for objects derived 
>  from GnomeCanvasItem.  I'm thinking here specifically of a GnomePlot widget, 
>  where the logical thing to do seems to be to derive various parts from the 
>  GnomeCanvasGroup.  Unfortunately, one cannot do this right now.

Right now you can modify an item's attributes using gnome_canvas_item_set().
You use it like this, for example:

	gnome_canvas_item_set (some_rectangle,
			       "fill_color", "blue",
			       "width_pixels", 9,
			       NULL);

This would change the fill color and the outline width to the
specified values.

>  Is there any need for the code that does:
>     gnome_canvas_group_child_bounds (group, NULL);
>  
>     if (item->parent)
>       gnome_canvas_group_child_bounds (GNOME_CANVAS_GROUP (item->parent), item);
>  
>  or is this a remnent of an older design (seen all over in gnome-canvas.c)?  it 
>  looks like gnome_canvas_group_child_bounds() calls its parent itself.

This function is used for two things.  If the specified item is
non-null, then it notifies the item's parent that the item's bounds
have changed, so the parent must update its own bounds and propagate
the change upwards in the item hierarchy.  This is done by just
"growing" the parent's bounding box to fit the new bounding box of the
child item.

If the specified item is NULL, then the parent is instructed to a)
reconfigure all its children, and b) recursive recompute all its
sub-groups bounds.  This is required when a group is moved, for
example -- all its children need to be reconfigured so that they will
recompute their bounding boxes.  Also, since the group's own bounds
change as a result of this, the group propagates the change upwards in
the hierarchy (the "if (item->parent) ..." bit).

When an item changes its bounds, it propagages the change upwards in
the hierarchy.  Since parent groups only update their bounds in this
case by growing their own bounding box, the effect is that bounding
boxes tend to become bigger over time.  Ideally, what would happen is
that when they become big enough to hurt performance (because extra
items are being repainted due to overgrown bounding boxes), the groups
should recompute their bounds from scratch (the NULL case described in
the paragraph above) to restore the "ideal" bounds.  This is not
implemented yet -- I have to think of some heuristics to know when a
bounding box is too big.

I could simply have groups rebuild their bounds non-recursively by
querying each of its children's bounding boxes, but I'm afraid that
would hurt performance when you have very wide item trees.  Maybe it
could be a selectable option, whether you want to grow bounding boxes
or query all the children, depending on the width of your tree.

>  passing 0 to gnome_canvas_item_raise() to raise an item to the top makes no 
>  sense.  This means that if there was a dialog allowing raising and lowering of 
>  items, the value 0 would have to be disallowed or checked for seperately (and 
>  one might want to allow altering several variables at once, in which case 
>  allowing 0 would make sense.)  seems like seperate functions 
>  gnome_canvas_item_raise_to_{top,bottom} would be better.

*Shrug*.  I can make separate functions for complete raise/lower if
you wish.  Using the special value 0 seemed nice at the time.

>  there needs to be a way to pass GdkColors instead of strings to creating 
>  items.  In fact, I would argue for this being the default, since most apps 
>  should allow configuration of the colors used, meaning that they would have to 
>  use a color selection box anyway.  It seems like one rarely wants a fixed 
>  color except in early prototyping.  It's also more efficient to use a 
>  GdkColor, of course.  Perhaps one should allow both?

The original implementation of the canvas (i.e. before it was
converted to use Gtk objects for the items) allowed using strings,
individual rgb values, and GdkColors for this.  Now that the canvas
items are Gtk objects and use the Gtk argument system, I haven't found
a way to pass a GdkColor.  I do want to add support for that.

>  Isn't using the GtkObject system going to get really slow when there are 
>  several hundred or thousand objects?  Someone should write up a test for this 
>  at least, and stick it in test-gnome.  Just stick up a bunch of rectangles 
>  every second, or something.

I don't think it will be slow at all.  I will write some speed tests
soon, to go in the canvas demo in gnome-libs/test-gnome.

>  Is there a reason why the interface uses the gnome_item_new to create all 
>  items, instead of having a per item creation call, such as gnome_rect_new 
>  (GnomeCanvas *canvas, GdkColor *fill_color, etc...)?  This seems easier from a 
>  programmer's point of view, and its not that much extra code.  Of course 
>  language bindings still need the get/set stuff.

That's a good idea.  I'll add these wrappers soon.

Thanks for your suggestions!

  Federico