Re: bug or feature

[Owen Taylor <otaylor redhat com>]

Damon Chaplin <damon@helixcode.com> writes:

> "Dr. Gerhard Dieringer" wrote:
> > 
> > I have the following situation: The toplevel window contains a vbox with
> > two elements. The first element is another vbox, the second is the
> > 'rest', with consists of a frame and a label inside.
> > The inner vbox also has two elements, the first one is a hbox with some
> > buttons, the second a 'data' widget.
> > The buttons can enlarge and shrink the data-widget, the 'rest'-widget in
> > the outer vbox should allways fill the rest of the top-level-window.
> > 
> > When i enlarge the data-widget, all works well, the rest-widget shrinks
> > as it should do.
> > But when I shrink the data widget, the rest isn't resized and I get some
> > vacuum above and below the data.
> > 
> > If I resize the top-level-window with the mouse or gtk_widget_set_usize
> > function, the rest-widget resizes and all is fine.
> > 
> > Is this a (known?) bug? I'm using GTK+ 1.2.8 on GNU/Linux.
> > 
> > In the attachment, you find a small programm that shows the effect. If
> > you uncomment the last two lines, that 'resize' the top-level-window to
> > it's current size, it works  as expected.
> 
> It does look like a bug. The queued resize initiated by gtk_widget_set_usize()
> doesn't seem to be propagating up the tree properly.
> 
> You can work around it by adding gtk_widget_queue_resize (dataframe->parent)
> after the call to gtk_widget_set_usize().

It's not really a bug. The way GTK+ works, a widget is only ever
guaranteed to be resized if the space it currently has is too
small for it's requisition. The requisition is a "minimum" size.

It might be a good idea to modify this to avoid the current
hysteresis effects. I have not gone through the consequences
of that for the implementation in detail.

Regards,
                                        Owen