Re: gtk_widget_queue_resize() forgetting allocation

On Tue, 2004-10-05 at 17:54 +0200, Tim Janik wrote:

> widget calls queue_resize from size_allocate, which causes
> queue_resize(sibling) (due to the GtkSizeGroup):
> ancestry	*		*
> widget		*		*
> sibling		* 		*
> end of first size_allocate phase:
> ancestry	* 		* 
> widget		* 		*
> sibling		* 		 	(got allocated)
> after another size_request and size_allocate round, this will lead to
> ancestry and widget being allocated new sizes, but will leave sibling
> unallocated (though it was requested a new size).
> calling gtk_widget_size_request() on a widget basically means:
> 1) call size_request on this widget (REQUEST_NEEDED set)
> 2) call size-allocate on this widget (ALLOC_NEEDED set)
> and having REQUEST_NEEDED and/or ALLOC_NEEDED set on a widget requires
> 3) all its ancestry up to its resize-container have those flags set as well,
> 4) its resize-container must be in the idle-sizer queue.

The way I'd think of this is that calling gtk_widget_size_request()
sets the REQUEST_NEEDED flag, and we have a set of invariants:

1) If REQUEST_NEEDED is set on a widget, REQUEST_NEEDED is set on
   all parents up to the resize container

2) If REQUEST_NEEDED is set on the resize container, the resize
   container has an idle queued on it.

3) If REQUEST_NEEDED is set on a widget, ALLOC_NEEDED will be
   set on a widget.

With the idle sizer behavior of calling request() than allocate()
on the toplevel, I think this gives the correct behavior that
queue_resize(widget) ensures ::request followed by ::allocate on
the widget.

As far as I can see, calls to gtk_widget_size_request() during 
size_allocate() still will handle 1) and 2) fine. The only problem
comes with 3), which my patch should fix up.


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]