Re: Canvas wedging on request_update()

[Erik Walthinsen <omega cse ogi edu>]

On Fri, 24 Sep 1999, Federico Mena Quintero wrote:

> 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.
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.

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

> 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.
In this case I think it works rather well, since the objects in question
are themselves just canvas item representations of the real objects, which
are the real data structure.  I'm visualizing doing the whole thing as a
separate set of data structures, and my brain's starting to hurt.

> 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.
In this case, I have the real objects sitting in a library, with their own
hierarchical structure.  When I create an editor* object, it is give the
pointer to the real object it shadows.  The editor object goes and creates
its children in the _realize() method, and handles the events associated
with moving and resizing.

In the case of the pad, it's set up to let the event pass through to the
parent container, which creates the wire object, grab()s, and deals with
subsequent events by moving the free end of the wire by setting x,y or the
pad the cursor is over at the moment.

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

> I will be happy to help you with this if you have problems.
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?  That seems less than
optimal, since that would cause the object to get another update() event.
Alternately, I might change the drag and resize event handlers to
request_update()s on both the object in question (after effecting the move
or risize) and the wires associated pads associated with that object.

TIA,
   Omega

         Erik Walthinsen <omega@cse.ogi.edu> - Staff Programmer @ OGI
        Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/
   Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/
        __
       /  \             SEUL: Simple End-User Linux - http://www.seul.org/
      |    | M E G A           Helping Linux become THE choice
      _\  /_                          for the home or office user