gnustep-dev
[Top][All Lists]
Advanced

[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 ;-)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]