Path: utzoo!utgpu!attcan!uunet!husc6!mailrus!cornell!uw-beaver!fluke!mce
From: mce@tc.fluke.COM (Brian McElhinney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: The Crunched Shell (long)
Keywords: Object-oriented programming
Message-ID: <4581@fluke.COM>
Date: 27 Jul 88 17:04:48 GMT
References: <2328@pt.cs.cmu.edu> <12362@agate.BERKELEY.EDU>
Sender: news@tc.fluke.COM
Organization: John Fluke Mfg. Co., Inc., Everett, WA
Lines: 36

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.

A "real" text class would be wonderful.  It should be something like a text
item in MacDraw.

The dialog class has taken a beating at meetings and in the MacApp DA
newsletter (so I have avoided it).  It would be useful to have classes for each
of the basic dialog items (buttons, check boxes, etc.) such that they can
appear in any view.  I think this is also in the next release.

The only grouping mechanism is the list.  To the programmer it appears to be a
dynamic array, not a list (i.e there is no way to ask for the next object; you
must keep an index yourself).  Other data types would be useful, and I'm sure
will appear as MacApp evolves and matures.

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

MacApp is a great tool, as it handles everything a commercial grade application
should (low memory, MultiFinder, printing), and makes many things much easier
(undo, updating multiple views of the same data, menu enable/disable).
Unfortunately, MacApp will not get the wide-spread use it deserves; not because
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++ ...


Brian McElhinney
mce@tc.fluke.com