Re: more on scrolled window sizing ... fixes + bugs?

[Paul Davis <pbd Op Net>]

>> Arg! I indeed set the policy to NEVER, but thats not at all what my
>> intended meaning is. Its set to NEVER because I don't want scrollbars
>> to be appear: the adjustments and the scrollbars for the scrolled
>> window are shared with other widgets (e.g. an adjacent scrolled
>> window). I did not mean for the child to be given as much space as it
>> desired.
>
>So change the child's desired space to your limit, say the limit
>dimension is vertical:
> gtk_widget_set_usize (child, -1 /* requisition */, 0 /* infinitely small */)

Nah, that doesn't work, because the child is a box, and its natural
size needs to be its natural size. We want to be able to scroll from
the bottom to the top of it, not compress its size.

The solution, which is almost complete, is the same as the one taken
by the Canvas itself: put the box into a Layout and then use the
layout directly instead of scrolled window or viewport. The vertical
expansion that used to take place when the box's natural size exploded
is now gone (naturally, since a Layout's requisition is never
dependent on its children). The only remaining problem is that the
box's width allocation is 1 (!), but I am pretty sure I can fix that.
 
BTW, there's a nice feedback loop possible when you do this:

     HBox { Layout | ScrolledWindow }

and then set the Layout adjustments to be those of the ScrolledWindow.
The allocation process goes into a nose dive. You have to leave the
Layout and ScrolledWindow adjustments independent, and set one when
the other changes.

--p