peterd@opus.cs.mcgill.ca (Peter Deutsch) (09/21/90)
In article <26590@boulder.Colorado.EDU>, hunt@boulder.Colorado.EDU (PUT YOUR NAME HERE) writes: > In article <92180@srcsip.UUCP> engstrom@SRC.Honeywell.COM (Eric Engstrom) writes: > >> [stuff about how X is being done on the NeXT - deleted...] > > > > > >Sounds good, but I've got a question... . . . > While I agree the NeXTStep is a nice GUI, what I don't think you understand > is the flexibility of X window. The "look" and behavior (window border, > gadgets, pop-up window, etc.) are all aspects of the X window _manager_, > which can be anything one desires (eg: twm, uwm, motif, openlook, etc.). > So I'm sure than someone could make a NeXTStepesque window manager to work > pretty much like it does now (although it would most likely be a bit slower). Actually, I was at the X conference in Boston in January and Brad Myer of CMU demoed Garnet, his testbed programming environment. As part of this work, his students prepared several "looks" to run under Xwindows, including a reasonable approximation of NeXTstep (buttons, sliders, the works!). I seem to recall this was to show off the portion of the project that allowed users to configure GUI interfaces. He made some joke about not wanting to be sued so it's not available. Still, if you don't distrbute, you can build it yourself. That's what makes X so valuable. "mechanism, not policy". It can be "messy, not polite" but it can do a lot. > The X window _server_ is what is common to all X window setups -- it's the > device that lets you communicate with X window clients (X window applications) > and other X window servers. This brings up a very neat concept of X -- the > idea that all X terminals are "equivalent" such that you can open a window > on any other X terminal (as long as you have permission). This is quite > handy when you want to show a window to someone remotely for their > pursal. The flexibility and gererality of X makes it a Good Thing. Further on this. We have a BBN parallel machine, which has a very nifty parallel debugger. Any workstation _RUNNING X_ can run this debugger, with the display on the workstation and the debugger on the BBN. Students can see graphically the actual timing of code firings, etc. Great for detecting timing dependent bugs, parallel execution etc. Now, this functionality is theoretically available in NeXTstep, but it will be some time (if ever) before BBN ports their debugger to NeXTstep. Why should they? They already have 99 percent of the workstation market covered now, with no recoding. Open the display, run debugger, go. That's why the world went with a standard. I think it was Dennis Ritchie who said "Steve Jobs has said that Xwindows is brain-damaged and will disappear in five years. He got it half right." - peterd ^X ^I .signature -------------------------------------------------------------------------- +-------+ Peter Deutsch McGill University | u # u | peterd@cs.mcgill.ca School of Computer Science |/\/\/\/| | a a | "From MAILER-DAEMON@hq.demos.su Thu Sep 13 00:45:55 MSD 1990" \ a / \___/ The day we made contact.... -------------------------------------------------------------------------- Look! I can type after the signature!