NeWS

Based on PostScript, NeWS started by modifing the PostScript interpreter to run in a cooperative multitasking[?] fashion. Unlike PostScript in a printer, NeWS would be displaying a number of PS programs at the same time, so some form of multitasking was required.

In addition, NeWS added a complete view hierarchy system, based on viewports known as canvases. Like the view system in most GUIs, it included the concept of a tree of embedded views along which events were passed. It also included a complete model for events (including timers and other "automatic" events), input queues for devices, and other functionality required for full interaction.

But by far the most interesting addition was a complete object oriented programming style with inheritance. This eliminated the need for an external OO language to provide a complete application.

Since all of these additions were added as additional PostScript keywords, it was possible to write simple PostScript code that would result in a running, onscreen, interactive program. For instance one of the common examples was an onscreen clock, which required about two pages of PS code.

NeWS also included a library (several actually) of user interface elements (widgets), written in NeWS. These widgets ran all of their behaviour in the NeWS interpreter, and only required communications to an outside program (or more NeWS code) when the widget demanded it.

For example, a toggle button's display routine can query the button's state (pressed or not) and change its display accordingly. The button can also react to mouse clicks by changing its state from pressed to not pressed and vice versa. All this can happen in the windowing server without interaction with the client program, and only when the mouse is released on the button will an event be sent off for handling.

Compare this to a "dumb" X Window System server, which can only report "mouse clicked on button" events to a client, which then has to switch the state, and finally instruct the server to display the new state. If client and server are not on the same machine, these interactions will have to travel over the network, slowing the feedback loop down unnecessarily.

Several companies licensed NeWS and adapted it for various uses. NeWS was later incorporated into Sun's OpenLook[?] system, where it was known as TNT (The NeWS Toolkit). There were only a few companies committed to this unproven technology. The OpenLook version of FrameMaker[?] by Frame Technology Inc.[?] at the time was one of the few products successfully run on NeWS. After it was clear that OpenLook was had lost out to Motif in popularity, and after Adobe acquired FrameMaker, products on NeWS simply vanished. Most UNIX workstations (including Sun's) run NeWS's competitor, X Windows.

The case can be made that a graphics engine where the code can be placed in either the screen engine or the application code needs to be considered as well, from any practical standpoint, Display PostScript had the same results for almost none of the complexity.

Why did NeWS fail?

There is no doubt that in many ways NeWS had a superior design for thin-networked clients, by moving much of the processing to the display, and separating graphical user interface semantics from client program semantics.

Possible reasons for its failure in the market include:

• PostScript is not a good programming language for humans
• writing NeWS apps required coding both client-side code and server-side code in two different programming languages
• NeWS may have been ahead of its time and user requirements in the sophistication level of its graphical and user-interface capabilities
• NeWS had much less of an advantage when the client and server ran on the same machine, and the network computing model never took off sufficiently to justify the extra complexity