[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: box system
From: |
Helge Hess |
Subject: |
Re: box system |
Date: |
Wed, 10 Apr 2002 10:37:34 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020310 |
Nicola Pero wrote:
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.
OK, I guess this is my misunderstanding. I thought that NSView (at least
conceptually) indeed holds an ordered collection of subviews and
therefore defines the view hierachy which is manipulated by -addSubview.
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.
Well, I still have a (uneducated) different opinion. Adding to the view
hierachy vs adding to the view hierachy ... The only thing we change, is
that we insert autolayout containers which enforce a layout restriction.
But I don't know enough about your box implementation.
Let me explain my idea about it:
a) NSView's defines a view hierachy by API
b) NSView's also define a resizing mechanism themselves
if the parent view size changes
c) by inserting autolayout containers we want to "disable"
b) and let the parent container handle the subview size
based on calculation
d) in my understanding NSView is also an "autolayout"
container, to be more specific, the thing which is called
"fixed" layout in gtk+.
e) I understood that -addSubview is too much a primitive as
to be used by "usual" user code
Is one of the assumptions completly wrong ? Eg you agree with d), why
should NSView do not have the -addView method (I would rename that
anyway, maybe -addLayoutManagedView: or something ?).
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.
If autoresizingmasks modify how autolayouting works in your
implementation, I would consider that a bug. What does happen if I
modify the masks after adding to the container ? If layouting is based
on it, it should change accordingly ?!
Further there can be widgets in a layout
container which are not managed, which is IMHO somewhat broken.
Where is the problem here ?
That it is broken ;-)
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.
OK, I can do this "forget" ;-) I understand that because -addSubview: is
obviously too much a primitive (see my assertions above).
But this doesn't explain, why NSView shouldn't support
-addLayoutManagedView: in a fixed-layout-container sense and therefore
provide a single, consistent API.
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.
Then it is broken too ;-) But in my understanding NSBrowser is a "leaf"
in the view hierachy since it is completly data driven ? In other words,
it would not permit -addManagedSubview: with an exception that it's a leaf.
But it isn't unlikely that NSBrowser works differently than I expect.
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.
OK. In my idea NSView's indeed are "autolayout" containers of type
"fixed layout". What's the point in switching abstractions during UI
development ?
If we cannot agree on this point (basically assertion d) ), I don't
think I like it ;-)
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.
I was talking about InterfaceBuilder (IB). If I drag a view from the
palette over a box, the box is highlighted and I can drop the view. IB
then does two things in my understanding: a) update the frame of the
view and b) call -addSubview on the the box. If the box is an
autolayout-container, -addSubview would more or less ignore the frame
but let the container do any calculation it wants to position and update
the frame. The default processing of the fixed-layout-container (NSView
;-) is keeping the frame and let the subview do resizing as he likes.
Also a vbox could still consider the initial coordinates to calculate
where to insert the subview in the layout array during "construction" mode.
If Gorm does different, then Gorm does different ;-)
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.
I agree with that. But I wonder how this should be catched ? I would go
like HTML and automatically insert a scrollpane if the minimum size of
the contentview is larger than the size of the window. Seeing clipped
views is IMHO a user experience as bad as seeing resized windows.
Greetings
Helge
--
DON'T PANIC ;-)