Re: Patch for GtkLayout (was: GnomeCanvas and zooming)

[Owen Taylor <otaylor redhat com>]

"Arjan J. Molenaar" <A J Molenaar xirion nl> writes:

> > From: Havoc Pennington [mailto:hp redhat com]
> > Michael Meeks <michael ximian com> writes: 
> > >         Ah; ok - we need to send the patch to gtk-devel; 
> > guys can you
> > > process this fix suggestion ?
> > 
> > It's in bugzilla, I mailed Arjan privately and pointed out the need to
> > do that.
> >  
> > >         Also; the gtk_layout_freeze/thaw is marked 
> > deprecated inside gtk+,
> > > so quite possibly we need to absorb this code into the 
> > canvas itself, with
> > > our own canvas freeze / thaw - if in fact this is 
> > neccessary; what do you
> > > think ?
> > 
> > No idea (as the deprecation comment says, it's unclear what layout
> > freeze/thaw even are supposed to do).
> > 
> > I would guess that GnomeCanvas internals need rethinking, since all
> > the flicker-avoidance and scrolling stuff now happens automatically. I
> > don't know if this has been done or not. I don't know if it matters
> > for this change...
 
> Can't GtkLayout be changed so that it will draw itself in during
> idle time (just like other widgets)? 

Are you referring to the gdk_window_process_updates() call in
gtk_layout_adjustment_changed? The call is in there, because, in my
experience, it looks very bad if scrolling gets ahead of updating, so
you always want to fill in the newly scrolled in areas once you
scrolled.

Other widgets that scroll do the same thing.

I'm still not sure what gtk-layout freeze/thaw was supposed to do, but
if you want to do simultaenous x/y updates, the standard technique
would be to poke the values into both adjusments then call
gtk_adjustment_changed and/or gtk_adjustment_value_changed on
both. The first signal emitted will do all the updates of the layout,
the later ones are only needed to handle the scrollbars.

Regards,
                                        Owen