Re: box system

[Helge Hess]

Hi Nicola,

somewhat late, but at last I'm going to process the box mails ;-)

Nicola Pero wrote:

> > 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 :-(
Yepp. Hopefully they fix that soon.

> Ok - I see your point then with dropping autoresizing masks from boxes as
> well.
No, this wasn't my point. My point is compatibility with some existing 
XML format, either XUL (which I would prefer) or Glade.
Anyway, this isn't the most important thing for me, first I would like 
to see a working any-xml sample (I didn't find the time yet to take a 
look at your model stuff :-( ).

> 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 :-(
Hm. I wouldn't drop this just because of MacOSX. Someone could file a 
bug and hopefully they fix that some time soon.

> > 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.
...
I think I understand your point, but I'm still unconvinced. If it's 
possible for us to use the same API, we should do, IMHO, even if this 
means more work for us during implementation.
If you still decide that you want to use -addView: or if it's really 
necessary anyway because of some technical aspect, I would vote that 
-addView add least becomes a standard category on NSView, so that *all* 
user code uses addView instead of addSubview.

> 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.
OK. I think gtk+ stores the layout information in "extra" attributes of 
the widget to be layouted and XUL uses a widget hierachy to represent 
that. Because of this, both do not require adding additional API for 
manipulating the view collection.
Anyway, the XUL or GSTable way seems most natural to me, gtk+ is IMHO 
broken in this aspect.

> 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.
Simpler for the developer of the code, but not for the user ;-) He needs 
to know about two different operations, adding managed widgets and 
adding non-managed widgets. Further there can be widgets in a layout 
container which are not managed, which is IMHO somewhat broken.
Anyway, if we invent a new API, this should at least be consistent for 
all NSView's.

> > 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 :-)
I'm not so sure about that ! I don't think that we can manipulate the 
way IB adds subviews dropped over boxes ! (Indeed we probably need to 
subclass boxes to make that possible at all !).

> 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) !
Sounds good.

Greetings
 Helge