Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!decwrl!nsc!voder!apple!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac.programmer
Subject: Re: The Crunched Shell (long)
Keywords: Object-oriented programming
Message-ID: <14935@apple.Apple.COM>
Date: 29 Jul 88 16:17:26 GMT
References: <2328@pt.cs.cmu.edu> <12362@agate.BERKELEY.EDU> <4581@fluke.COM>
Reply-To: lsr@apple.apple.com.UUCP (Larry Rosenstein)
Organization: Advanced Technology Group, Apple Computer
Lines: 55

In article <4581@fluke.COM> mce@tc.fluke.COM (Brian McElhinney) writes:
>elcond@garnet.berkeley.edu (Gregory Dow) writes:
>> People have commented that they have had difficulties or are not satisfied
>> with MacApp.  Does anyone have any SPECIFIC gripes which they would like
>> share?
>
>I have always been amazed that views (drawing areas inside windows) are tiled.
>Overlapping views would have been far more useful, an indeed are rumored to be
>a part of the next release (as are C++ and a symbolic debugger).  Also, you
>should be able to nest views inside views.

Overlapping views are not directly supported in MacApp 2.0. Views can
overlap, but MacApp does nothing to prevent one view from interfering with
another.  The views will be drawn in a particular order and, one view will
end up covering part of another.

It should be easy to implement true overlapping views in the same way
overlapping windows are implemented.  You would have to maintain a visRgn
for each view in the list, and override the Focus method to clip to the
view's visRgn.

MacApp 2.0 does support arbitrary hierarchy of views.  The dialog unit is
completely redone, and dialogs done with MacApp don't use the Dialog
Manager.  Instead they are regular windows.  There are many view classes
predefined in the Dialog units, to correspond to all the standard controls,
as well as control-like objects that are not really controls (popup menus,
pictures, icons, lists of items, etc.).

The view hierarchy is defined by a resource, and there is work being done on
a graphical editor for view resources.

>The basic window class is, well, kind of basic.  Multi-pane windows (such as
>in Excel) would be a great addition.

You can do this in MacApp 1.1, and it will be a bit easier to do in MacApp
2.0.  MacApp directly supports windows with a fixed-size "palette" at the
top or left of the window.  More complicated window arrangements are
possible if you override the window class and implement code to resize and
move its subviews when the window resizes.

MacApp 2.0 does not directly support splitting a view into independently
scrollable parts that display the same information.  Again, the view
architecture in MacApp 2.0 makes this easier to implement than it was in the
old MacApp.

>of faults in MacApp itself, but because using it means using MPW (i.e.: slow
>and expensive).  Now if there was such a thing as LightspeedC++ ...

Well eventually, there will be Lighspeed Pascal 2.0.

		 Larry Rosenstein,  Object Specialist
 Apple Computer, Inc.  20525 Mariani Ave, MS 46-B  Cupertino, CA 95014
	    AppleLink:Rosenstein1    domain:lsr@Apple.COM
		UUCP:{sun,voder,nsc,decwrl}!apple!lsr