Re: Canvas wedging on request_update()

>  Doesn't the _request_update() function just set a flag and add the idle
>  handler?  I would think that'd be safe enough, but if not, well, I guess
>  I'll deal.

It does that, but that does not make it re-entrant :-)

The purpose of doing updates in the idle loop is that at that point
the application has finished fiddling with its data structures and can
go on to accept more user input.  Since all data manipulation is done,
it is optimal to refresh the display, which could be expensive.  If
you look at this, you'll see why updating more items at that time,
i.e. doing more computation, would defeat the purpose of the delayed
update model.

>  When it comes time to move the objects in question, I need some way to
>  cause the wires to move with it.

This sounds a lot like what we did in Gnoghurt.  Check out the
`gnoghurt' module from the GNOME cvs.  It lets you place filters and
connect them with wires, and when you move a filter, the wires move
with it.

>  How would you suggest I go about dealing with this problem, as is?  Can I
>  arrange for the element to send a signal or something its parent
>  container, forcing it to update all its children?

If you have a Pad object, you could make it emit a signal when it gets
moved by its event handler.  Then the wires would catch that signal
and move themselves.

When everything is done, the items' ::update() methods will be
magically called :-)


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