On Mon, 27 Sep 2004, Owen Taylor wrote:
I'm not *completely* sure this should be considered a GTK+ bug, since
what you are doing is fairly marginal. But there is a fairly easy
fix, which would be, in gtk_widget_size_allocate(), do:
alloc_needed = GTK_WIDGET_ALLOC_NEEDED (widget);
-
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
On Tue, 5 Oct 2004, Owen Taylor wrote:
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
On Tue, 2004-10-05 at 21:10 +0200, Tim Janik wrote:
On Tue, 5 Oct 2004, Owen Taylor wrote:
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
On Mon, Sep 27, 2004 at 12:35:54PM -0400, Owen Taylor wrote:
So, I'd actually appreciate it if you could file a bug in bugzilla
with your test case as an attachment and a link to this analysis
in the mail.gnome.org archives.
Done.
Two easy workarounds for your problem you might want to try:
For posterity:
I isolated the issue to the GtkViewport widget. I found that if I packed the
label/vbox into a GtkLayout and packed that into the GtkScrolledWindow,
the size negotiations worked the way they should. I don't know if the
problem is caused by some function of the viewport that I
No one has any insight here? It seems to me that a call to
gtk_widget_size_request() should be followed by a gtk_widget_size_allocate()
when generated by a gtk_widget_queue_resize(), especially if the program goes
idle.
Is there something about the size negotiation process that I'm
Hello,
I've run into an issue in a program I'm writing where sometimes a call to
gtk_widget_queue_resize() ends in a request rather than an allocate. I've
put together a short test case (tested in GTK+ 2.4.4) which keeps the spirit
of the program intact (see below).
First, a little context --
