Re: Resizing of subviews

[richard]

On Sunday, November 5, 2000, at 04:11 PM, address@hidden wrote:

> While digging into a problem with the resizing of a text view inside a 
> scroll view, I did get the impression that our current implementation of 
> the resizing of sub views works only for a single sub view, that fills 
> out 
> all of its super view. 
> When a view gets its frame changed, all the sub views get a call to the 
> method resizeWithOldSuperviewSize: with the old size of the super view. 
> Now every sub view tries to resize itself to the full change of the 
> super view. If there are more than one sub view or if the sub view does 
> not 
> fill up the full size of its super view, that resizing will be to much. 
> (As can be seen by make a text view with restricted width inside of a 
> scroll view and making that scroll view first wide and than small 
> again.) 
> I would now recommend, that all the sub views will try to resize them 
> self proportional to their old size (relative to the old super view 
> size). This will give better results in a lot of cases, but will lead to 
> unused space if there are many sub views but only one of them is 
> resizeable in any way. 
>  
> Are there any other ideas for that problem? 

The current implementation is (I'm pretty sure) the behavior used in 
OPENSTEP/MacOS-X.
It works very nicely on those systems - and in GNUstep apps that I've seen.
I think perhaps you are overlooking the use of the autoresizing mask for each 
subview -
this mask is critical to the control of the resizing behavior.

For instance, if you have a view with three subviews (eg two buttons and a 
textfield)
lined up in a row inside it, you might set the leftmost subview to have a 
resizable
right margin, the middle subview to have a resizable right margin, and the 
rightmost
subview to have resizable width.

When the view is widened, the left and middle subviews (buttons) would stay the 
same size
and same positions relative to the left edge of the view, while the right 
subview
(textfield) would expand to fill the space made by the widening of the view.

This sort of scheme gives the programmer (or user of InterfaceBuilder / Gorm) a 
very
simple mechanism to have a high degree of control over layout without having to 
resort
to custom coding.

For automated proportional sizing of multiple subviews, Nicola has written 
GSTable,
GSHBox and GSVBox which probably have something like the sort of behavior you 
are
thinking of.  He wrote some nice documentation for them too - but I can't 
remember
where that is.