Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!dogie.macc.wisc.edu!uwvax!rutgers!mit-eddie!uw-beaver!cornell!rochester!pt.cs.cmu.edu!wb1.cs.cmu.edu!avie
From: avie@wb1.cs.cmu.edu (Avadis Tevanian)
Newsgroups: comp.sys.next
Subject: Re: NextStep and NeWS...
Keywords: NextStep,NeWS,Postscript
Message-ID: <4793@pt.cs.cmu.edu>
Date: 21 Apr 89 09:24:49 GMT
References: <1041@nixctc.DE> <8530@polya.Stanford.EDU> <3901@ficc.uu.net> <4759@pt.cs.cmu.edu> <3918@ficc.uu.net> <4779@pt.cs.cmu.edu> <11532@cgl.ucsf.EDU>
Organization: NeXT, Inc.
Lines: 60

In article <11532@cgl.ucsf.EDU> conrad@zeno.mmwb.ucsf.edu.UUCP (Conrad Huang) writes:
>The problem with trying to program in DPS is that there is no way to
>communicate with the window server other than through the AppKit.  (I
>have read parts of the manual but by no means all, so correct me if I'm
>wrong.)  This means you must at least use Objective C to create an
>Application class object.

It is possible to communicate directly with the window server in a C
program.  No appkit, no Objective C is necessary.  It's probably buried
somewhere in the documentation, but I am not sure.  (We have added
operators to Postscript to handle events, they are not part of DPS, per se).

>Unfortunately, those of us on the same network but not running Mach cannot
>"synchronize with the window server" at all.  The advantage of NeWS is that
>I can run my application on our Vax and have the graphics appear on our Sun
>*using only standard network software*.  With some of the computation that
>we would like to do, animating the results requires a supercomputer class
>CPU.  Unfortunately, I don't know of many such systems that run Mach or
>speak with NeXT window systems.  I certainly agree that the greater
>the bandwidth between the application and the window server, the greater the
>programming flexibility.  But connectivity should count for something as well.
>

As the song goes, "Don't worry, be happy!"  Our Postscript window server,
in addition to listening to Mach ports, also listens on a TCP socket.  In
0.8, this functionality is built into the window server.  In 0.9, we
moved it out to a special "protocol converter" program which listens
on the TCP socket and converts to Mach IPC.  This means you can connect
to our window server from any machine that supports TCP.  When we make
Mach a standard, this won't be necessary :-).

>The main gripe I have with NextStep currently is that there is no *simple*
>graphics access.  If I am working on an application that will have a user
>interface, then NextStep may be helpful.  But I can't simply use the graphics
>to help debug a program.  When my translator/compiler runs, I'd like to
>show my DAG and make sure it is right.  I'd also like to highlight nodes when
>I generate code for them.  To do this, I must create a whole lot of code that
>will eventually be discarded (or at least archived) once my program works
>properly.  The time investment for this debugging code is greater than I am
>willing to spend and I've resorted to the old classic "print statement" method.
>With a nice platform like the NeXT, this is somehow distasteful.
>

this should be *very* easy to do.  With Interface Builder you can get
an "empty" application with no programming.  Now drop in your graphics
routines, using Postscript to do the graphics of course.  And if you
wish, just ignore the Application Kit and the rest of NextStep.  But
while your in IB, why not add an Info Panel, and a Help Window, they require
no programming and come essentially for free along with your free
menu, resizeable window, close box, ...

And if you want, you can even ignore all of this and just hook up directly
to the window server (I forget the call, but its documented) and draw
your postscript directly.

-- 
Avadis Tevanian, Jr.    (Avie)
Chief Operating System Scientist
NeXT, Inc.
avie@cs.cmu.edu or avie@NeXT.com
--