Re: Size allocation and redrawing issues

[Tim Janik <timj gtk org>]

On 3 Nov 2001, Owen Taylor wrote:

> > >  * If you call gtk_widget_queue_resize() on a widget, that must result
> > >    in:
> > >   
> > >     - a call to gtk_widget_size_request() on the widget
> > >     - a call to gtk_widget_size_allocate() on the widget
> > >     - the widget being redrawn
> > >   
> > >    Currently, all three of these will propagate to descendents
> > >    of the widget, but I don't think there is actually any real
> > >    requirement that the second two propagate (except as required
> > >    by changing allocations, and propagation of exposes to NO_WINDOW
> > >    children.)
> > 
> > urm, i know some containers/children make use of that
> > propagation knowledge. basically, they can assume (for resize containers):
> > 
> > queue_resize(child); => size_request+size_allocate on parent (though
> >                         size_allocate only happens if the parent grew),
> >                         size_request+size_allocate+redraw on child
> > queue_resize(parent);=> size_request+size_allocate+redraw on parent,
> >                         size_request+size_allocate+redraw on _immediate_
> >                         children
> 
> OK, these still all hold true except for:
>  
>  queue_resize(parent);=> size_request+size_allocate+redraw on _immediate_
>                          children
> 
> The immediate children of parent will only be requested if
> size_request was done on them or their descendents, size_allocate only
> if the allocation changed, and redraw only if the allocation changed
> (or they are no-window widgets.)
> 
> I can't think of any reason anything would be depending on the
> last.

adding to/removing from containers does. currently container
implementations are free in their _add() handler to either
queue the resize on the container or the newly added child.
(though with current code, it'd even be sufficient to just
queue a resize on some random other unrelated child of the
container, that's a setup that i don't think we need to
maintain).
so i guess this boils down to, how do you ensure:
- the child requisition/allocation is being considered
  invalidated/new upon add and reparent
- the container gets redrawn if a child got removed/added,
  even if its allocation and requisition didn't change upon
  add/removing a child?

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ