Re: xpdf status ... yet another day.

[Federico Mena Quintero <federico redhat com>]

>  Let's say my component looks like this:
>      ________   ________         -
>     | Button | | Button |        | 10 pixels
>      --------   --------         -
>   |----------------------|       -
>   |  Document goes here  |       |
>   |                      |       |
>   |                      |       |
>   |                      |       | 50 pixels.
>   |                      |       |
>   |                      |       |
>   |                      |       |
>    ----------------------        -
>  
>  (Putting buttons in the component might be wrong, but you can surely
>  imagine other scenarios where there will be non-scalable "border"
>  pixels).
>  
>      So when the component gets scaled, its container cannot just
>  allocate it (height * zoom_factor) pixels for the component's height.
>  The idea here is that the component itself must specify its new size.

Hmmm.  I can imagine that you would want stuff like this, for example,
on a GIMP image component.  An unfocused component of that type would
be a simple image display.  However, when it gets activated for
edition, the image would stay the same size and the component's
effective area would grow to accomodate the GIMP's rulers around the
image.

In this case, I think the container should tell the child what its
"normal" area is, but then the child is free to request a bigger area
for editing purposes.  As a matter of policy, I wonder whether we can
constrain children to not allocate a bigger area than told to when
they are *not* being edited (the purpose of this being to provide as
WYSIWYG a view as you can).

  Federico