don@brillig (Don Hopkins) (02/08/88)
> Date: 1 Feb 88 17:04:00 GMT > From: necntc!dandelion!ulowell!apollo!dawson@husc6.harvard.edu (Keith Dawson) > > Apollo currently has no plans to support the NeWS product. Apollo's window > strategy is based on the X Window System. > > Apollo's Open Dialogue UIMS, along with other recent developments such as > Adobe's Display PostScript product, address the issues of user interface > development and PostScript capabilities under X in a manner we feel to be > superior to NeWS. NeWS has extensions to the PostScript language that allow for programs (light weight processes), running in the display server, to receive input events on behalf of NeWS clients (other programs running on the same computer, or at some remote site). They may process input locally (on the same machine and in the same process where the events are happening), without consuming any communications bandwidth. This is a big advantage, if you want fast, responsive graphical feedback. NeWS processes can communicate with each other by manipulating shared data structures, and by sending messages through the event queue. They can receive low level input events ("The left mouse button was released at location (X,Y) in window W at time T"), and give graphical feedback ("erase the old slider, redraw it at its new position, and fill the border with bright red"). They can translate input from the user into high level, application specific events, which are sent to the client ("set the volume of the CD player to 100%"). NeWS processes can run autonomously in the server, without a connection to a client, providing "desk accessories" such as a calculator, event journaling, menus, and control panels. According to the fellow from Adobe who talked at the PostScript BOF at the X conference, Adobe's Display PostScript provides output capabilities, but has no facilities for receiving input directly from of the X event queue. As I understand his explanation, the X server must send X events over the IPC link (network, shared memory, modem, or whatever) to the client, which must then translate the events into PostScript commands, and send them back over the link to be executed by Display PostScript. Because there is no way for PostScript programs to read events off of the X event queue, the client must process input events behalf of the display server. Messages must go on a round trip, from the X server, to the client, and back to the Display PostScript extension in the server, to produce any graphical output on the screen. In answer to a question, the Adobe representative said that Display PostScript does not go through the X GC (graphics context), but instead, uses its own graphics libraries. I'd like to know just how device dependent these libraries are, and how much work is involved in porting the Display PostScript extension to a new piece of hardware? At the X conference, in her talk about Sun's merged X11/NeWS server, Robin Schaufler explained that X11/NeWS, which will be Sun's enhanced and supported X11 server, consists of two parallel protocol interpreters, on top of the same graphics library. The X11 protocol interpreter and the NeWS "PostScript based" language interpreter are both written in C. They both use the same event queue, and the same "forest" of windows. (A forest of windows is a group of trees of nested windows, on different displays, controlled by one server.) NeWS processes can draw on X "windows" and X clients can draw on NeWS "canvases", because windows and canvases are the same thing. NeWS and X clients can communicate with each other through the single event queue. NeWS processes communicate over IPC links with X clients by using special primitives to encode and decode X events. The NeWS "Lite" user interface toolkit is written entirely in PostScript. Menus, buttons, windows, sliders, scroll bars, and even terminal emulators, are implemented as device independent PostScript programs, in NeWS's object oriented PostScript programming environment. Since the toolkit can run in the server, clients can share the same code, and a copy of the toolkit does not have to be linked into each client. It's easy to modify and customize the NeWS toolkit and user interface, and NeWS clients can use the modifications without having to be changed, recompiled, or relinked. Since you at Apollo seem to feel that that Display PostScript under X11 is a better alternative than Sun's X11/NeWS merge, I'd like hear how it is that you think Display PostScript can support the type of user interface development environment that NeWS does. And if you've got a better idea, I'd sure like to hear about that, too! > Another advantage is that X is a public-domain window > system, making it accessible to the entire industry. Will Adobe's Display PostScript be in the public domain? I sure doubt it! How available will the source code be? And how much will it cost? Will there be educational discounts? How will it be distributed? The X11/NeWS server will be distributed by AT&T as part of their normal source distributions, and no license with Sun will be required. That's certainly accessible if you ask me! I would dearly love to see both NeWS *AND* Display PostScript end up in the public domain, where they belong! But both companies have a bunch of very good people putting a lot of hard work into development and support. But Sun's sure not making a lot of money by selling NeWS binaries at $100 a pop. Besides a tape and a NeWS manual, they include two of Adobe's very own books on PostScript, the Red and Blue PostScriptures. > Most important of all it the fact that the marketplace has chosen X as the > industry standard window system. > > > Ross Chapman, Apollo Computer > !decvax!apollo!chapman_r That's exactly why Sun is supporting X11. The NeWS/X merge didn't happen over night, ya know! -Don
richard@gryphon.CTS.COM (Richard Sexton) (03/05/88)
Sombody "who is in charge of that stuff" @ apollo, told me at the 87
ADUS meeting that Apollo will have a NeWS/X merge product.
Just like Sun.
--
"...(alright Nils, alright)..."
richard@gryphon.CTS.COM
{ihnp4!scgvaxd!cadovax, rutgers!marque, codas!ddsw1} gryphon!richard