From: andrew@cubetech.com
Subject: Re: specifically comparing NeXT with Mac...
Organization: Cube Technologies, Inc.
Date: Mon, 9 Nov 1992 20:31:32 GMT

In article <lsr-051192110110@lsr.taligent.com> lsr@taligent.com (Larry Rosenstein) writes:
>In article <1992Nov5.120538.2602@cubetech.com>, andrew@cubetech.com wrote:
>> 
>> of Quickdraw or lack thereof compared to PostScript, but the fact that
>> with DPS, you have the same imaging model for _all_ output.  Unless
>> QDGX is a DPS clone, you are still where you used to be: you still
>
>Or unless there's a 1-1 mapping from QDGX to Postscript.  The problem today
>is that QuickDraw doesn't support a lot of things that Postscript does.  My
>impression is that QDGX will support more (if not all) those things.

It's not just doing the same things as DPS (more of not all?  I'd
definitely like to see it...), you'd have to be a DPS clone.
Otherwise you stille have to translate all your QDGX code to PS to
print (if possible).  Additionally, if it's not written by Adobe, then
there is no guarantee that you will get the same thing on the printer
without a lot of tweaking around (who wants to do that).  It will
still be better than vanilla QD.

>> have to write code to draw to the screen, and code to draw to the
>> printer.  A unified imaging model is the biggest win with DPS.  It
>
>In general, you don't have to write separate code, unless you need to use
>direct Postscript code.  Presumably QDGX will reduce the need to write
>directly in Postscript.

Well, since the printer can't understand QD, you have to generate the
PS code somewhere.  It depends on what you are doing.

>> Interface Builder is different.  When you "draw" your interface, you
>> are really creating the actual objects that will be instantiated when
>
>Exactly what happens when you use Apple's ViewEdit.  The view objects are
>saved in a resource and read in at runtime.  The main difference is that
>Interface Builder has more support for defining interactions between
>objects than ViewEdit does.

You are also not limited to views with IB.  You can do things with any
object (and define your awn objects within IB as well).

>> limited to sending 32k, and I don't think they work over the network.
>
>Apple events are network transparent.  Except for the 32k limit, you could
>send MacApp objects in an Apple event as well.

Yes, but how easy/difficult is it to use AppleEvents.  With DO's I
don't have to write any additional code, so I use them constantly
(especially for synchronized drawing between threads in my own app).

>> NeXT objects do most of the drudge work for you when writing an an
>> app.  The AppKit provides classes - most notably Window and View -
>
>The same is true of MacApp.  Although I think MacApp is narrower and deeper
>(it has more support for basic things like Undo and documents) while NeXT's
>kits are broader and shallower.  MacApp also takes the tedium out of
>writing Mac applications.

You've sent me mail before about this and you've always used the same
example - "undo and documents."  An Undo object is provided in 3.0 and
really I can't see the point of a document object besides the Object
superclass.


If having MacApp and all these other tools was as good as having and
object-orient operating system like NeXTSTEP, Apple wouln't be
spending all this money on Pink/Taligent.


andrew
Newsgroups: comp.sys.mac.advocacy