Widget resize behaviour differs depending on how I resize the window


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

|       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:

gnome_app_size_allocate_signal(GtkWidget *widget,
			       GtkAllocation *allocation,
			       GtkDrawingArea *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.


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