Re: box system

[Nicola Pero]

Just thought I would Cc: gnustep-dev as it might be interesting to others

> >>Do your boxes need AppKit autoresizing ? I ask, because autoresizing is 
> >>seriously broken on MacOSX.
> > 
> > Hmmm ... argh ... what do you mean ? can you make an example ?
> 
> Yes. Take InterfaceBuilder, place 3 Buttons in a row into a window and 
> set each button to autoresize, autoposition (all width springs 
> selected). (exactly what a vbox does ;-)

No ... it's not what a hbox does - otherwise we wouldn't need hboxes :-)

autoresizing masks are an inferior autoresizing mechanism (inferior to
boxes), which - basically - only works for very simple setups.

In particular, it's impossible - in general - to replace a box with
autoresizing masks (unless you introduce intermediate views of course).  
I know this was the result of my investigations on the matter.  (Let me
see if I can remember now the details ...)  This is why I think [hv]boxes
are a missing piece of the AppKit, and we bundle them by default with
gnustep-gui ... because it's just impossible to keep three expanding
buttons in a row (under autoresizing) without boxes. :-)

 
> Now go into test mode and grab the resizing control of the window and 
> move around quickly for some seconds (5 or so). Soon the buttons will 
> start to break out of their position (usually the left button starts to 
> move to the right and soon all buttons will overlap).
>
> No pattern can be seen in this misbehaviour. I can only guess that there 
> is a rounding bug or something like this.

Ok - there might be rounding errors, but the problem is that each button
is resized/repositioned independently of the other ones, and is
resized/repositioned relative to the superview ... as if it were the only
subview.  There is no way to constrain the relative position of the
buttons.  The buttons move and expand freely - each one independently of
the other ones - and they can easily end up overlapping.

Imagine that you have only 2 buttons.  It's impossible to do what you want
with 2 buttons as well so I'll explain myself with 2 buttons.

At the beginning, the first button will have a distance A1 from the left
border of the window, a distance B1 from the right border of the window,
and a width C1.  The second button will have a distance A2 from the left
border, a distance B2 from the right border, and a width C2.

<---A1--->[FIRST BUTTON]<------------------------------B1-->
<---------------------------A2---->[SECOND BUTTON]<---B2--->

Please note that the distance between the two buttons is 

A2 - (A1 + B1)

If you increase the width of the window by K, then because you've set
everything to autoresize, the increase in width K will be equally divided
between widths and minX and maxX borders ... in other words,

A1_new = A1 + K/3;
B1_new = B1 + K/3;
C1_new = C1 + K/3;

A2_new = A2 + K/3;
B2_new = B2 + K/3;
C2_new = C2 + K/3;

that looks like OK and it would be OK if you consider each button
separately - but if you consider the interaction between them it's not -
the distance between the buttons is now

A2_new - (A1_new + B1_new) = 

 = A2 + K/3 - (A1 + K/3 + B1 + K/3) =

 = A2 - (A1 + B1) - K/3 = original_distance - K/3

so the distance between the two buttons is diminuished by K/3 ! If K is
large enough, that might very easily cause the distance to go below 0,
which means the buttons overlap.

the distance between the origins of the buttons should remain constant in
all cases instead (if you set NSViewMinXMargin in the autoresizingmask for
both of course) - but the problem is the buttons do expand ... the first
button expands, and since the origins of the buttons stay at the same
distance, the expansion of the first button makes the right edge of the
first button to get closer and closer to the left edge of the second
button ... till at some point the ugly thing happens, and the first button
starts to overlap the second one.

if the buttons do not expand (ie, if you set the buttons autoresizing mask
to NSViewMinXMargin | NSViewMaxXMargin, but no NSViewWidthSizable), then
the button should not overlap, and the distance should be constant in
time.


Normally, if you want to check for rounding errors, you should resize the
window a lot, then return it to the original size.  If the buttons return
to the original position, there should be no rounding error.  If on OS X
the buttons do *not* return to the original position, then well yes it's
not just a weak API which can't manage serious autoresizing ... it's also
a deadly broken implementation ... but I don't think it's that broken -
seriously, it can't be. :-)

Anyway - I'm of course curious (I don't have a OS X to test) to know if
it's really broken or not. :-)