ali@polya.Stanford.EDU (Ali T. Ozer) (04/18/89)
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
peter@ficc.uu.net (Peter da Silva) (04/18/89)
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? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
jtn@zodiac.ADS.COM (John Nelson) (04/19/89)
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. Can anyone at NeXT (or someplace) please explain why NeXTStep is a better division of labour than NeWS? NeWS has some attractive features. The only problem is that it isn't a real shell of any kind ... i.e. Sun is still stuck in this "run a thing on top of the cshell" model. Sine Visa Ars Nihil Est - John T. Nelson
avie@wb1.cs.cmu.edu (Avadis Tevanian) (04/19/89)
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. -- Avadis Tevanian, Jr. (Avie) Chief Operating System Scientist NeXT, Inc. avie@cs.cmu.edu or avie@NeXT.com --
peter@ficc.uu.net (Peter da Silva) (04/20/89)
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... -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
conrad@cgl.ucsf.edu (Conrad Huang) (04/21/89)
In article <4779@pt.cs.cmu.edu> avie@wb1.cs.cmu.edu (Avadis Tevanian) writes: >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. Perhaps comparing user interface specifications is appropriate, but comparing DPS with NeWS definitely is not. DPS provides output capabilities only, while NeWS is a complete window environment *including input management*. It is possible to write a program for NeWS and be guaranteed that it will work on most NeWS systems (modulo bugs) but there is *absolutely no way* to write a portable DPS program. >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. 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. >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). If InterfaceBuilder is an integral part of NextStep, I am certainly glad that "Interface Builder is greatly changed in its appearance" (from the "0.9/1.0 Release Description"). The version on Release 0.8 is at best a toy. Better data flow style editors have been built, even for the Evans & Sutherland PS300 function networks (my one gratuitous insult in this posting :-). [Even further off the subject, the PS300 function networks are hell, regardless of what they say in comp.graphics.] >>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. 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. >>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. 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. >-- >Avadis Tevanian, Jr. (Avie) >Chief Operating System Scientist >NeXT, Inc. >avie@cs.cmu.edu or avie@NeXT.com >-- Eagerly awaiting 0.9, Conrad Huang conrad@cgl.ucsf.edu
gore@eecs.nwu.edu (Jacob Gore) (04/21/89)
/ comp.sys.next / avie@wb1.cs.cmu.edu (Avadis Tevanian) / Apr 18, 1989 / >The thing to remember about NextStep is that you generally program in C or >Objective-C (or Common Lisp or Objective Fortran). Objective Fortran??? Jacob Gore Gore@EECS.NWU.Edu Northwestern Univ., EECS Dept. {oddjob,chinet,att}!nucsrl!gore
avie@wb1.cs.cmu.edu (Avadis Tevanian) (04/21/89)
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? -- Avadis Tevanian, Jr. (Avie) Chief Operating System Scientist NeXT, Inc. avie@cs.cmu.edu or avie@NeXT.com --
avie@wb1.cs.cmu.edu (Avadis Tevanian) (04/21/89)
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 --
mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel) (04/22/89)
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
peter@ficc.uu.net (Peter da Silva) (04/24/89)
In article <4792@pt.cs.cmu.edu>, avie@wb1.cs.cmu.edu (Avadis Tevanian) writes: > Exactly my point! You can't write everything in Postscript. You shouldn't > have to write everything in Postscript. Who the hell said you should? > 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? What if you want to fix perceived flaws in NextStep, or enhance it? How do I change NextStep to use pac-man menus? Or use the second mouse button effectively? Or suppose I want to use your applications under my UI? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) (04/25/89)
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 :-)rossh@umd5.umd.edu (Hollis "NeXT-Dood" Ross) (04/28/89)
In article <12670022@eecs.nwu.edu> gore@eecs.nwu.edu (Jacob Gore) writes: >/ comp.sys.next / avie@wb1.cs.cmu.edu (Avadis Tevanian) / Apr 18, 1989 / >>The thing to remember about NextStep is that you generally program in C or >>Objective-C (or Common Lisp or Objective Fortran). > >Objective Fortran??? > >Jacob Gore Gore@EECS.NWU.Edu >Northwestern Univ., EECS Dept. {oddjob,chinet,att}!nucsrl!gore Steve Jobs said that they have plans for Objective-Cobol. He was just joking, but the concept sure does give me the willies. :-) ================================================================================ "Gozer the Gozarian, as a duly appointed represenative | rossh@umd5.umd.edu of the, State, County and City of New York, I do hereby | Bitnet: rossh@umdd command you to cease all paranormal activity and return |--------------------- forthwit to your place of origin, or the nearest | Bill the cat says convient parallel dimension" - Ghostbusters | "Just say Ack!" ================================================================================