duanev@kauai.ACA.MCC.COM (Duane Voth) (08/17/89)
Can anyone give a good reason for the following code in the Viewport's
DoLayout() routine?
if (XtIsRealized(w)) {
if (((ViewportWidget)w)->viewport.allowhoriz)
geometry.width = Min(w->core.width, /* childs requstd */ width);
if (((ViewportWidget)w)->viewport.allowvert)
geometry.height = Min(w->core.height, /* childs requstd */ height);
} else ...
When a child of a Viewport requests to be enlarged, this code is
executed and forces the child to either be as big as the current
Viewport size, or smaller. Thus, Viewport children cannot expand
without getting saddled with scroll bars even when the Viewport's
parent is perfectly happy to accommodate an enlarge/resize request.
Perhaps this code reflects a preference for invoking scroll bars over
asking a parent for more room. If so, it is an annoying assumption.
In my current application, I want scroll bars only if the Viewport's
parent refuses to let the Viewport grow.
duane
--
--- duane voth duanev@mcc.com
---- ALL systems are arbitrary!
--- effectiveness is the measure of Truth
--swick@ATHENA.MIT.EDU (Ralph R. Swick) (08/17/89)
> In my current application, I want scroll bars only if the Viewport's > parent refuses to let the Viewport grow. That's a perfectly reasonable enhancement request. The original semantics of Viewport were that it never changed its own size after it was realized. Adding a `resize' Boolean option will go on our TODO list.