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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
