This is NextStep-and-NeWS... in view mode; [Up]
Date: Sun 17-Apr-1989 23:00:26 From: Unknown Subject: Re: NextStep and NeWS... 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 >From: feldman@umd5.umd.edu (Mark Feldman)
Date: Sun 19-Apr-1989 01:23:58 From: Unknown Subject: Re: NextStep and NeWS... In article <7605@zodiac.UUCP> jtn@ads.com (John Nelson) writes: >In article <3901@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >>In article <8530@polya.Stanford.EDU>, ali@polya.Stanford.EDU (Ali T. Ozer) writes: >>> 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... >> >>Is this really so desirable? I thought NeWS' model was a very nice division >>of labor. You get a much greater degree of user programmability as well. Why >>is it more desirable to hardcode interface decisions into the application? > >This is a very important question I think. The premise behind the question is wrong. Nothing is hard coded into an application, other than the fact that it is using windows/views/menus/etc. The implementation of these classes, i.e. NextStep, presents a single, uniform user interface to the user. Anyone can subclass these classes and get new behaviour, but at the risk of presenting a different user interface. The thing to remember about NextStep is that you generally program in C or Objective-C (or Common Lisp or Objective Fortran). If you have some complicated graphics that you wish to use, you can drop into Postscript whenver you wish, but we generally find that programming in C is much easier than Postscript.
Date: Sun 19-Apr-1989 20:23:29 From: Unknown Subject: Re: NextStep and NeWS... In article <3918@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >I think it's a good idea to move user-interface policy decisions out of the >application and into the user-interface. NeWS seems (so far as I can tell >from reading usenet) to have done this, by implementing so much of the user >interface in postscript. [ user programmability ] > Well, I think the confusion here is perhaps that making NextStep/NeWS comparisons is the wrong comparison. It would be more appropriate to compare NextStep with the Mac user-interface or Open Look... It would also be more appropriate to compare DPS with NeWS. NextStep defines a user-interface, DPS/Objective-C/C provide a base for an implementation of it. If you want to write your own user-interface, then you can program it in DPS if you wish. We are just saying that programming in DPS (or NeWS) is, in general, a pain. Let's also not forget that an important part of NextStep is InterfaceBuilder, which let's one build NextStep user-interfaces for applications with very little to no programming (other than the guts of your application). >The second advantage to this is that more of the processing of the user- >interface can go on in the display server, freeing the host and communication >channel of the burden. [ division of labor ] The importance of this is somewhat questionable (I think). The fact that people even think about this these days is because the environment they are used to (e.g., UNIX with sockets) just doesn't do message passing fast enough. When you are doing animations (for example), do you really want to write your animation in Postscript, of course not, and we don't. What if your animation needs to be synchronized with sound effects? Do you write that all in Postscript also? No, of course not. The basic problem with X/NeWS/... environments is that the generally run on top of UNIX, and UNIX just doesn't have the right primitives to support them (in terms of high speed message passing). We have overcome this problem by using Mach primitives which allow us to synchronize with the window server about 10 times faster than with traditional UNIX facilities. >Personally, I think a lisp-like language would be better than postscript, but >there is a certain historical advantage to sticking with PS. Then you'll be happy to use Common Lisp with support for NextStep in our 1.0 release.
Date: Sun 20-Apr-1989 14:39:18 From: Unknown Subject: Re: NextStep and NeWS... In article <4779@pt.cs.cmu.edu>, avie@wb1.cs.cmu.edu (Avadis Tevanian) writes: > NextStep defines a user-interface, DPS/Objective-C/C provide a base > for an implementation of it. If you want to write your own user-interface, > then you can program it in DPS if you wish. We are just saying that > programming in DPS (or NeWS) is, in general, a pain. Mainly I'm talking about whether your UI is bound in with the application or not. More on this at the end of this article. > >The second advantage to this is that more of the processing of the user- > >interface can go on in the display server, freeing the host and communication > >channel of the burden. [ division of labor ] > The importance of this is somewhat questionable (I think). I disagree... it's pretty important. Not because... > The fact that > people even think about this these days is because the environment they > are used to (e.g., UNIX with sockets) just doesn't do message passing > fast enough. ...not because sockets are too slow, but because the communication channel may be. I can buy an Acer Xebra 1000 for $1000 and hook it onto an ethernet or SLIP serial port and run X remotely. It would be more efficient to run NeWS on the server instead... send menu selection events instead of bitmaps. The following is a digression... > When you are doing animations (for example), do you really > want to write your animation in Postscript, of course not, and we don't. Hell no. I'd rather do animations in Director's scripting language, or in forth. Write forth programs to generate videoscape 3-d animation files. Which takes me back to postscript, now doesn't it? > What if your animation needs to be synchronized with sound effects? What if it needs to be driven by MIDI? "What if" is a trademark of HP :->. > The basic problem with X/NeWS/... environments is that the generally > run on top of UNIX, and UNIX just doesn't have the [ high speed message > passing]. We have overcome this problem by using Mach ... about 10 times > faster than with traditional UNIX facilities. But it's still not real-time. How many messages a second could you pass through a pipeline containing say, a MIDI input port, a couple of filters, to a MIDI output port and the DSP? Not entirely relevant, but I do think that *as yet* the advantages of Mach haven't fully gelled. I believe it will eventually become the final solution to te real-time-UNIX problem... but it's not there yet. Anyway, back to the point. Animation really isn't a user-interface process so it's kind of a straw man... I'm not talking about doing EVERYTHING in DP or NeWS or VideoLisp or whatever. I'm talking about a division of labor between the UI and the application. This division of labor question is still wide open. I certainly haven't seen anyone claiming they've solved it. > >Personally, I think a lisp-like language would be better than postscript, but > >there is a certain historical advantage to sticking with PS. > Then you'll be happy to use Common Lisp with support for NextStep in our 1.0 > release. But I can't write Common Lisp code and change the global behaviour of my desktop. The interface policy decisions are still tied up in compiled code. What if I want to use pac-man menus? What if I want to use that second mouse button for something useful? Like having it pop up menus instead of leaving them around all the time? Pac-man menus? With the DSP going wocka-wocka- wocka...
Date: Sun 21-Apr-1989 09:10:11 From: Unknown Subject: Re: NextStep and NeWS... In article <3931@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >...not because sockets are too slow, but because the communication channel >may be. I can buy an Acer Xebra 1000 for $1000 and hook it onto an ethernet >or SLIP serial port and run X remotely. It would be more efficient to run >NeWS on the server instead... send menu selection events instead of bitmaps. We don't send bitmaps, we send Postscript. I make the point about speed of communication because it is most important when you need to do round-trip communication between application and window server. This simple fact means that if you expect applications to ever need to interact with the window server is a fast fashion (for sound, more computation, or whatever), the speed of doing that round-trip communication is key to application performance. It doesn't matter if 99.9% of the application is in Postscript, because if that .1% needs fast interaction with the window server and you have a slow communication path, you lose. > >The following is a digression... > >> When you are doing animations (for example), do you really >> want to write your animation in Postscript, of course not, and we don't. > >Hell no. I'd rather do animations in Director's scripting language, or in >forth. Write forth programs to generate videoscape 3-d animation files. >Which takes me back to postscript, now doesn't it? > Again, only if everything is in postscript. How about adding sound effects now? And music synthesis in the DSP? And... >> What if your animation needs to be synchronized with sound effects? > >What if it needs to be driven by MIDI? "What if" is a trademark of HP :->. > Exactly my point! You can't write everything in Postscript. You shouldn't have to write everything in Postscript. >But it's still not real-time. How many messages a second could you pass through >a pipeline containing say, a MIDI input port, a couple of filters, to a MIDI >output port and the DSP? > We have done experiments with the music kit controlling synthesised instruments running in the DSP using MIDI input and it does work in real-time. >Not entirely relevant, but I do think that *as yet* the advantages of Mach >haven't fully gelled. I believe it will eventually become the final solution >to te real-time-UNIX problem... but it's not there yet. Glad to see you have faith in Mach. I agree with you here, there is much more work to be done here to fully solve the problems but we are well on our way. > >Anyway, back to the point. Animation really isn't a user-interface process >so it's kind of a straw man... I'm not talking about doing EVERYTHING in >DP or NeWS or VideoLisp or whatever. I'm talking about a division of labor >between the UI and the application. Yes, and we agree, we have a layer of NextStep known as the "packages" which is that part of NextStep that runs entirely in the window server. It does things like window movement, activation, ... And as it turns out, you as a user can load your own packages. It doesn't allow to reimplement the entire UI, but then again, if you do that, you don't have NextStep anymore. Remember, it makes little sense to reimplement window/menus/... at the NextStep layer, because you no longer have NextStep. If you want to implement a different UI and allow for everything to be rewritten you can certainly do that in DPS. So, can we lay this to rest by saying that NextStep is a specific UI for which it make no significant sense to reimplement features and that if you want to have a UI in which any feature was user-implementable you could write it in DPS?
Date: Sun 21-Apr-1989 09:24:49 From: Unknown Subject: Re: NextStep and NeWS... 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.
Date: Sun 22-Apr-1989 00:33:43 From: Unknown Subject: Re: NextStep and NeWS... In article <4792@pt.cs.cmu.edu> avie@wb1.cs.cmu.edu (Avadis Tevanian) writes: > >Yes, and we agree, we have a layer of NextStep known as the "packages" which >is that part of NextStep that runs entirely in the window server. It does >things like window movement, activation, ... And as it turns out, you >as a user can load your own packages. It doesn't allow to reimplement >the entire UI, but then again, if you do that, you don't have NextStep >anymore. Remember, it makes little sense to reimplement window/menus/... >at the NextStep layer, because you no longer have NextStep. If you want >to implement a different UI and allow for everything to be rewritten you >can certainly do that in DPS. > > >So, can we lay this to rest by saying that NextStep is a specific UI for >which it make no significant sense to reimplement features and that if >you want to have a UI in which any feature was user-implementable you >could write it in DPS? Ok, here's the big question. Is the _user interface as seen by the user_ separate from the window system? Is the "toolkit interface" seen by the programmer separate from the window system? Here's what I mean: I can see that if somebody wanted to do a totally different kind of user interface, this programmer would have to create all the structures &c and write the appropriate code to display them. That's fine, you can't expect the given system to be omniscient enough to do everything for you. But here's the other question: can you replace the code & appearance/superficial features of the user interface, but maintain the same programmer interface so that existing programs will work in this new way without change? For example, taking a Mac analogy, I might want to make some window type with a "close box" that's greeen & polka-dotted that you need to hit control-twaddle-double-bucky-left-mouse to activate, but from the application's point of view, you've still just hit the "close box". How much do the applications programs assume about the particular _implementation_ of the user interface? (not very much I hope) If you have shared libraries, this might be practical. A customizable but still compatible user interface. >-- >Avadis Tevanian, Jr. (Avie) >Chief Operating System Scientist >NeXT, Inc. >avie@cs.cmu.edu or avie@NeXT.com >-- Matt Kennel mbkennel@phoenix.princeton.edu >From: bob@allosaur.cis.ohio-state.edu (Bob Sutterfield)
Date: Sun 24-Apr-1989 20:44:16 From: Unknown Subject: Re: NextStep and NeWS... In article <4793@pt.cs.cmu.edu> avie@wb1.cs.cmu.edu (Avadis Tevanian) writes: 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 :-). Will I be able to get source to your toolkit sometime after Mach becomes the standard? Because I don't want to go to the trouble of porting Mach to all the various machines on our network just to find- that they still can't do anything useful to display on the NeXT box. It's not that I wouldn't love to have Mach everywhere, but NeXT compatibility isn't big on my list of reasons to go ahead with the effort - especially since I wouldn't have NeXT compatibility even then. Even if your server listens on a TCP socket, it doesn't do me any good unless I can write and compile NeXTStep applications on the Butterfly down the hall (which already does Mach ports anyway) and the Cray across campus (which likely will never run Mach). I think you can do more to advance NeXT's cause by releasing sources. (Does this sound like a broken record, anyone?) (BTW, I'm really glad to see more NeXT presence here, particularly of those "in the know"! Don't let the ferocity of some of the opinions change your mind about participation - only about policies :-) >From: lih@cunixc.cc.columbia.edu (Andrew Lih)
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.