Re: GNOME CVS: gnumeric jody

[Lauris Kaplinski <lauris ariman ee>]

On Sun, 2 Apr 2000, Federico Mena Quintero wrote:

> Yup.  The update cycle is not reentrant.
> 
> You should not call request_update() on yourself or other items inside
> your ::update() method.  For extra safety, you should not emit signals
> from inside ::update(), either, since the handlers may do evil stuff
> that requests updates on the same canvas.
> 
> As Chris has pointed out, there is some trouble when you have a canvas
> group that wants to modify its children's attributes inside its
>::update() method.  His specific example is the reflow item for the
> Evolution card view.  It wanted to do reflows of its children in the
>::update() handler, but that involves changing the children's
> attributes, which would in turn request updates and screw up the
> update cycle.
> 
> The solution I proposed was to install an idle handler with a
> higher-than-normal priority for reflowing.  Then, the handler runs
> before the canvas' own idle handler and you do your reflow operations
> there.  Afterwards, the canvas updates the items normally.
> 
> I was looking at some Gnomecal code and came up to the GnomeMonthView
> item.  This is a canvas group that holds a bunch of rectangles and
> text items and uses them to display a cute little monthly calendar.
> When you change an attribute of the GnomeMonthView item to select the
> displayed month, it synchronously recalculates the month's dates and
> changes its children's attributes, i.e. changing the text items to
> display the proper day numbers.
> 
> If the GnomeMonthView item were to defer updating of the day numbers
> until the idle loop, then I would have to do something similar to what
> Chris does in the card view in Evolution.
> 
> I am not satisfied with the way this is dealt with in the canvas. The
> way it works is
> 
> 	1. Resolve application-specific updates (changing day numbers,
>            reflowing cards).
> 
> 	2. Resolve canvas-specific updates (recompute bounding boxes,
>            request redraws).
> 
> What I don't like is that (1) has to be done by installing an idle
> handler with a higher priority than (2).
> 
> Suggestions?
> 

1. Move clearing of item flags from update method to the end of
gnome_canvas_item_invoke_update (), so it is guaranteed to happen after
the end of item update
2. gnome_canvas_item_request_update does not propagate back to canvas,
if parent has NEED_UPDATE flag set

So, if you have specific group, whose update method modifies its children
BEFORE its ancestor (GnomeCanvasGroup) update method is called, these
children should behave well. (they are updated during group ancestor
update method, which is guaranteed to be called after modifications, and
update request from children cannot pass our group)

just my thoughts

Lauris