Re: box system

[Nicola Pero]

> >>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.

Using the same API for different things is not useful - it is confusing
and wrong.

-addSubview: is a primitive which adds a subview independently of other
subviews and of the parent's frame.

-addView: adds a view as the last view in the array of views managed by a
box container; it creates an intermediate subview to manage the view (so
the view which is added does not even become a direct subview of the box!
it would be impossible otherwise to manage it); it resizes the box frame;
it modifies all other subviews frames - which is turn changes the frame of
all other views managed by the container - to update them for the new
view.

In the field of gui layout/autoresizing, these two things are as much
different as they could possibly be.  They have *nothing* in common.  
After -addSubview:, the parent's view frame is the same as before.  The
other subviews are untouched.  After -addView:, the container's frame is
NOT the same as before.  The other views are NOT the same as before.  
-addSubview: ignores the subview autoresizing mask.  -addView: does NOT
ignore the view autoresizing mask.

Which implies that the calling code must behave *completely* differently
when it calls -addSubview: and when it calls -addView: - they have
completely different effects (the change in the parent's frame is
particularly relevant here, but also the autoresizing masks etc are so
completely different).

So - since the calling code must behave completely differently it's just
correct that the methods have a different name.


> 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.

A box holds an ordered array of views.  -addView: is named after
-addObject: (NSMutableArray).  A generic view does not hold an ordered
array of views, so it makes no sense to have -addView: in that case.


 
> >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. 

Yes - he needs to know about two different operations, because there are
two different operations.

-addView: is substantially different than -addSubview:.  It does different
things.  Completely different things.  Sure the user/developer has to
learn a new API ... because the new API does different things.  The
user/developer CAN'T use -addView: thinking it's the same as -addSubview:.  
It's completely different.  He MUST learn the new API to use it properly.

Just another example - you can use -addSubview: and call
setAutoresizingMask: on the subview after adding it to the superview.  It
makes no difference if you set it before or after.  You can't use
-addView: instead unless you have called setAutoresizingMaks: *before*
calling it.

Using the same name would hide the differences, while the differences are
essential.  You can't even use it if you don't know the differences.


> Further there can be widgets in a layout 
> container which are not managed, which is IMHO somewhat broken.

Where is the problem here ?

Just forget about -addSubview: for boxes and you are happy.  You should
never call -addSubview: for boxes (unless you know what you're doing of
course) because that means touching its internals.

This is no different than a NSBrowser.  You can call -addSubview: for a
NSBrowser, and mess it up by adding unmanaged subviews to it.  NSBrowser
manages its subviews, yet you can still call -addSubview: in it.


> Anyway, if we invent a new API, this should at least be consistent for 
> all NSView's.

Generic NSView are *NOT* autolayout containers.  They only support
absolute layout.  Boxes are autolayout containers.  They only support
automatic layout.  The API MUST be different to stress the difference in
implementation and philosophy.

 
> >>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 :-)

No - this would not work this way - because all the space of a box is
completely filled by its subviews (which are *NOT* the views the box is
managing, they are intermediate views).  So if you drop a view on a box,
the drop would be taken either by the actual views managed by the box (and
the view dropped would be added as subview to something which is managed
by the box) or by the intermediate internal views of the box (and adding
the view as subview to them is a completely different concept which makes
little sense here), but never by the box, since the box has not even a
single pixel which is not covered by a subview.

So - to drop views on boxes you can't use addSubview: anyway.  That will
never work.

Anyway, just since I'm here - once you've found a way to add views to
boxes, there is still some code to write to have that work in Gorm.

There are basically two ways autolayout works - one is when the user
resizes the window - then the resizing propagates from top (the window)
down to subviews.  OpenStep has some basic support for this autoresizing.

The other autolayout it when a view inside a box is resized (eg, in Gorm
because the view is made bigger).  Then, the resizing of the view should
propagate from bottom (the view) up to superviews and to the window.  
OpenStep has no built-in support for this.  Sure the API is rich enough
that we can implement it (particularly if we only use our own custom
classes as containers), but there is not even a standard method to do that
... since this kind of autolayout only makes sense for containers (boxes),
which OpenStep doesn't have.

I don't think our boxes support this second autolayout mechanism.  Unless
inside IB, I think this second autolayout mechanism is harmful, because we
don't want windows to resize themselves automatically (as it often happens
in gtk which btw used to always make windows bigger, but never shrink them
back when the views inside shrink back).  Windows should only be resized
by users, not by software.

So, this autolayout mechanism would be normally disabled (as it is), and
you would turn it on by calling some special method ... that would only be
done inside Gorm.  If you turned it on, the box would track frame changes
in the views it manages ... and update the box size as the subviews' frame
change.  If the box was the window's contentView, we would then update the
window's size.