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): > REQUEST_NEEDED ALLOC_NEEDED > ancestry * * > widget * * > sibling * * > > end of first size_allocate phase: > REQUEST_NEEDED ALLOC_NEEDED > 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. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part