Re: GNOME CVS: gnumeric jody

[Lauris Kaplinski <lauris ariman ee>]

On Tue, 4 Apr 2000, Lauris Kaplinski wrote:

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

I again reply to myself ;-)

The beforementioned solution works only with group immediate children. In
floyd, I used 2 methods, which allowed requesting update while in idle
loop.

1. Former method:
(in floyd_idle)

while (floyd->need_update) {
	floyd_item_invoke_update (floyd->root);
}

2. Present method:
(in floyd_idle)

if (floyd->need_update) {
	floyd->need_update = FALSE;
	floyd_item_invoke_update (floyd->root);
}

if (!floyd->need_update) {
	.... DO RENDER ....
} else {
	.... INSTALL IDLE HANDLER AGAIN ....
}

The problem with these is, that sometimes object will do 2 or more
uopdates during one cycle - but you probably cannot resolve this,
without creating new signals and/or methods for application updates. But
actually I'm not sure, how often somebody will need to modify foreign
object (not immediate child) asynchronously during update.

Actually there was still third method for timers, which installed
proprietary signal handlers, sorted by evocation time... And fourth, which
installed OpenGL list handlers, sorted by relative importance (viewpoint
before lighting & so on...)

What about adding 2 signals:
GnomeCanvas::start_update
GnomeCanvas::stop_update

Regards,
Lauris