Widget resize behaviour differs depending on how I resize the window

[Pascal Haakmat <a haakmat chello nl>]

Hello,

I have a app with an interface that looks like a bit like this (the
interface was generated using Glade and is loaded at runtime using
libglade):

+---------------------+
|       GnomeApp      |
|+-------------------+|
||     GnomeDock     ||
||+-----------------+||
|||     GtkHBox     |||
|||+-------------+-+|||
|||| DrawingArea |1||||   1 = GtkVScrollBar
||||             |1||||
|||+-------------+-+|||
+++-----------------+++

I need to show/hide the scrollbar "1" depending on the size of the
DrawingArea. I do this by performing a gtk_widget_show()/hide() call on the
scrollbar in the DrawingArea's "configure" signal handler.

One way in which the size of the DrawingArea can change is obviously because
the user resizes the window. And when resizing windows by dragging their
corners everything works as expected.

However, when using the window manager's (sawmill) "maximize" function, it
does _not_ work. That is, the scrollbar disappears, but the DrawingArea is
not appropriately resized; leaving an ugly grey bar in the place where the
scrollbar used to be (expand and fill are enabled for all containers).

Finally I got the desired resize behaviour for the DrawingArea by attaching
the following function to the "size_allocate" signal for the enclosing
GnomeApp window:

void
gnome_app_size_allocate_signal(GtkWidget *widget,
                               GtkAllocation *allocation,
                               GtkDrawingArea *drawing_area) {
   while(gtk_events_pending())
     if(gtk_main_iteration())
       return;
   gtk_widget_queue_resize(drawing_area);
}

This workaround relies on that the assumption that the "size_allocate"
signal for the DrawingArea always arrives before the "size_allocate" signal
for the enclosing GnomeApp window. Is this a safe assumption to make?

More generally, is this the way it is supposed to work, or might this is a
bug? I'm using GTK 1.2.9.

Thanks.