From: lsr@taligent.com (Larry Rosenstein)
Subject: NeXT AppKit vs. MacApp
Followup-To: comp.sys.mac.advocacy
Organization: Taligent, Inc.
Date: Mon, 4 Jan 1993 23:16:31 GMT

In article <1992Dec21.080207.9359@cubetech.com>, andrew@cubetech.com wrote:
> 
> I think that's the biggest load of BS I have ever heard from you,
> Larry.  Doesn't concentrate on depth?  WHERE?  I have found that in
> areas that NeXT has created a kit, they have coverd it very, very
> well.

It's hard for me to be really specific because I'm not an expert on
NeXTStep.  I'll give some examples of things MacApp does, and you can tell
me if these are handled by the AppKit.  ("You" in this case is the
programmer.)

* MacApp has a framework for command handling.  You implement a command
object and hand it back to MacApp and it takes care of updating the state
of the Undo menu item, undoing the command, etc.  I don't think the AppKit
has this, although one of the sample apps that comes with 3.0 describes
this kind of functionality.  But as far as I could tell this isn't standard
in the AppKit itself.

* MacApp has a lot of document-handling code.  When saving a document, you
have to implement the writing code and figure out how much disk space you
need, but MacApp takes care of creating the file checking the free disk
space, etc.  MacApp implements the Save As and Save A Copy commands using
these same routines.

* MacApp has a framework for reporting errors to the user.  You have to
test for errors, but if one if found MacApp takes care of putting up the
appropriate dialog.

* MacApp handles the standard Mac dialogs, such as the one prompting the
user to save the document if it has changed.

I know that NeXT has kits that cover a wider range of things, such as Sound
& Music, Indexing, Text, Images.  That's what I meant by it being broader. 
MacApp in general concentrates of the details common to all apps and has
ignored the optional "kits" that one might want to use.

> Not all apps are document oriented.  Also, the implementation of a
> document varies so widely from application to application that a
> generic document object would be so abstract as to be almost useless.

But for all apps that save documents, the saving code is structured the the
same way.  A criticism of MacApp 2 is that the document model didn't work
for apps like databases.  MacApp 3.0 is supposed to address this, but I
haven't seen anything to say whether it was successful or not.


> What exactly does the MacApp document class do?  Things like menu
> enabling and other context sensitive operations are handled by the
> Application object and object delegates.

The document class handles the common aspects of opening & saving
documents.  It doesn't do anything about the actual data of the document.

In MacApp there are a number of objects at runtime that are each
responsible for enabling the menu commands appropriate to it.  It doesn't
make sense for the Application object to deal with the Save command.


> MacApp also doesn't have IndexingKit, 3DKit, DataBaseKit, PhoneKit,
> DistributedObjects, MusicKit, a language with full dynamic binding,
> threads, memory zones, fast IPC with copy-on-write direct memory

Some of these things (like IPC) are not in MacApp's domain.  Those are O/S,
language, etc. issues.  While it's true that MacApp only works on the Mac,
I think these are separate issues.

Larry Rosenstein
Taligent, Inc.

lsr@taligent.com