Re: Canvas wedging on request_update()

[Federico Mena Quintero <federico redhat com>]

[snip snip snip!]
>  So the question is, what's going wrong with this thing?  Is there a reason
>  I can't call gnome_canvas_item_request_update() from within an _update()
>  call?  From the gnome-libs code it is clear that it recurses up the parent
>  chain, which shouldn't be a problem I wouldn't think.  The immediate
>  parent of the wire is the container that holds the two objects (which in
>  turn hold the pads that the wire is 'connected' to).

The update cycle is not reentrant.  That is, the ::update() method of
items should not emit signals that could cause the handlers to do
something that would trigger an update request.  Likewise, your
::update() method should not do anything that would trigger an update
request from other items.

This is similar to Gtk+; you should not request a resize in your
::size_allocate().

I think the problem you are having is a common one.  I am writing new
widgets for icon lists / column lists / trees, and I am using a
model/view type of abstraction.  I have found out that this is very
convenient and makes things a lot simpler and cleaner.

In your case, it seems like you are trying to use the canvas as your
main data structure.  This is not what the canvas is designed to be.
The canvas is a display engine, not a generic hierarchical data
structure.

Ideally you would have a "model" with all your data, and another
"view" interface that takes that data in the model and creates and
updates the corresponding canvas items as needed.  Your model would
have notification signals to tell the world that some part of its data
changed, and then the view(s) would update themselves appropriately.

This also has the advantage that you can have more than one view onto
the same data.

In your case, I would have something like

	Model {	
		signal pad_added (node);
		signal pad_removed (node);
		signal pad_changed (node);

		signal wire_added (wire, pad1, pad2);
		signal wire_removed (wire);
	}

then your view would capture those signals and map them to operations
on canvas items as appropriate.

I will be happy to help you with this if you have problems.

  Federico