Re: GNOME CVS: gnumeric jody

[Federico Mena Quintero <federico helixcode com>]

>  Module name:	gnumeric
>  Changes by:	jody	00/04/02 15:05:37
> 
>  Log message:
>  Chris is 'Da Man' (tm) !
>  
>  After much wasted thought effort and hair pulling the problem boiled
>  down to me not realizing that it was bad to request and update for a
>  canvas item from an update routine even for a different canvas item.

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?

  Federico