Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!shelby!polya!ali From: ali@polya.Stanford.EDU (Ali T. Ozer) Newsgroups: comp.sys.next Subject: Re: NextStep and NeWS... Keywords: NextStep,NeWS,Postscript Message-ID: <8530@polya.Stanford.EDU> Date: 17 Apr 89 23:00:26 GMT References: <1041@nixctc.DE> Sender: Ali T. Ozer Reply-To: aozer@NeXT.com (Ali Ozer) Organization: . Lines: 30 In article <1041@nixctc.DE> pete@relay.nixctc.de (Pete Delaney) writes: > ... I just scan thru the NeXt news >group and expected a bit more postscript programs being exchanged >as in the comp.windows.news news-group. One of the goals of NextStep is to make sure the programmer does not have to write any more PostScript than is necessary to do the his/her custom drawing. All user interface objects exist in Objective C and are created/manipulated/destroyed using Objective C as opposed to PostScript. The Application Kit routines do all the drawing necessary to render the UI objects (buttons, switches, menu items, text items, etc). You even get a set of C functions (NXDrawRidge, NXDrawWhiteBezel...) to let you easily draw boxes and various other constructs without using PostScript. Typically you will write most of your program in ObjC or C and drop to PostScript whenever you want to do some custom drawing. (It's possible to embed PostScript code in C or ObjC files, by the way.) If you try to bypass the Application Kit and do all programming in PostScript, you will lose the user interface support and most of the window system functionality provided by the Application Kit. (I think in NeWS most of the user interface support is in PostScript, so it is possible to program entirely in PostScript... Is that correct? I don't know for sure.) All this does not mean you cannot execute a stand-alone PostScript program in the NextStep environment; you can. You can either use a previewer such as Yap or Preview, or use PostScript operators such as "run" from your own programs... Ali Ozer, NeXT Developer Support aozer@NeXT.com