Re: scrolled windows, again

[Havoc Pennington <hp redhat com>]

Paul Davis <pbd op net> writes: 
> the problem is that the scrolled window(s) are packed into:
> 
>     a table thats inside
>     an hbox thats inside
>     an eventbox thats inside
>     a vbox thats inside
>     a top level window

This can be worked around by setting a geometry widget
(set_geometry_hints()), if you do that then the default size applies
to the geometry widget instead of the whole window.

> The size of the top level window has been set, but the scrolled
> windows are either too big (they extend below the bottom of the top
> level window unless i resize it) or too small (actually, 1 pixel high
> if i request no scrollbar).

I'm not sure how you manage either of those; if the SW has
POLICY_NEVER in a direction, it should pass on the child size request
in that direction; and a widget extending beyond the toplevel just
isn't supposed to happen. Maybe you have allow_shrink turned on in the
window policy, or usize set on the toplevel? Either is a questionable
idea because it allows widgets to get less than their requisition.
Requisitions are effectively minimum sizes, usize and allow_shrink
hose everything up and by overriding requisitions.
 
> BTW, while i'm here i'd like to mention the horrible behaviour of the
> Canvas in trying to center itself within its allocated area if the
> scroll region is smaller than that area. You specify a scroll region
> of, say (0,0) to (100,100) and because the allocation is actually
> 150x150, the entire canvas pads itself out to move the origin (0,0) to
> (25,25) within in the allocated space. Yuk. Its truly horrible
> behaviour :) Shall I file a bug report on this?

I have no idea about the behavior, but in general I think filing bug
reports if you think something might be bad is a good thing, at worst
someone closes the report.

Havoc