Re: box system

[Nicola Pero]

> > 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. :-)
> 
> It is. The effect is, that the buttons start "jumping around". For some 
> time it works well (as you describe), but at some point (rounding error 
> ?), the buttons are positioned totally wrong.

:-(

this is unbelievable :-(

Ok - I see your point then with dropping autoresizing masks from boxes as
well.

Yes - we could potentially rewrite the boxes to drop the autoresizing
masks - since they only work properly in gnustep - and layout a completely
new API for placing views in boxes, completely separated from the
traditional openstep autoresizing masks.  I'm unconvinced of doing this,
yet I don't see any way to have the markup stuff work properly on OS X if
we don't get boxes properly working first :-(

 
> BTW: Is still don't understand why you don't override addSubview: for 
> layout-containers since all subviews should be positioned by the 
> container ? 

because it would make the code a mess.

overriding addSubview: in this way is a very bad idea.  it's like
overriding a basic primitive - which is needed and used in a lot of places
- to do something very high level and complex (NB: addView: in a box moves
the new view around, adds it as subview of an intermediate view, enlarges
the box by one row/column, changes even the frame of the box itself!) -
then you have to try and write a lot of workarounds for all the places in
which you call the basic primitive (normally in super's implementation)
thinking it's a basic primitive and instead it's doing something very
complicated. <cfr encoding/decoding a NSBox, where addSubview: is
overridden to add a subview to the only actual subview, and so super's
decoding/encoding, which encodes/decodes the list of subviews and upon
decoding adds them using addSubview:, is broken and you need to uglily
work around this and it confuses people>

Anyway - in the specific example, all the layout is done by a superclass,
GSTable.  This superclass has rows and columns, and you put new views into
the appropriate row and column using putView:atRow:column:etc:etc: methods
which lay out the new view using addSubview: etc.

GSVbox is a simple superclass which implements an addView: method which
enlarges the GSTable by one row, puts the view in the new row, manually
manages borders etc If that method would override addSubview:, then the
superclass would use that very complex implementation instead of the
addSubview: primitive it is expection, and nothing would work (you likely
enter into loops).

GSHbox is the same.

As usual, if you allow for complex workaround you can get around with it,
but the fact is that it is much simpler if 'addSubview:' does waht it is
supposed to do, and the higher level code is accessed using a different
method.

> But I still have you read your other mail ;-) Eg that would 
> do very nice with IB, since subviews dropped into a box would be 
> autoresized :-)

I suppose there is a way to make this work with addView: as well :-)

NB: it would be desirable anyway, because if I drop a view in the middle
of a hbox, I want the view to be inserted in the middle of the hbox, not
at the end (as addView: would do) !