10 ms·

NeWS – Network Extensible Window System

86 points by stevewilhelm 11y ago

tilt_error 11y ago
PostScript really is a lovely programming language. Some 20 years ago, I used a development environment (PSAlter) that made it quite palatable -- visualising dictionaries and stacks -- and made it possible to step through programs. There exists a nice free e-book describing PostScript (Thinking in PostScript by Glenn C. Reid) [1]. [1] https://web.archive.org/web/20000914161447/http://www.rightbrain.com/download/books/ThinkingInPostScript.pdf https://web.archive.org/web/20000914161447/http://www.rightb... EDIT While looking for the Thinking in PostScript book mentioned above, I stumbled upon this legal online archive for books on the net [2] which may be of interest to others. [2] http://onlinebooks.library.upenn.edu http://onlinebooks.library.upenn.edu
- tonyedgecombe 11y ago
  PSAlter is still available: http://www.quite.com/psalter/psalter.htm#order http://www.quite.com/psalter/psalter.htm#order
- DonHopkins 11y ago
  That's very cool! I'd like to see more about how the debugger works. Are there any video demos available, please? I love Glenn Reid's book, Thinking PostScript. It's like the Thinking Forth [1] of PostScript! ;) I always thought of PostScript as a cross between Lisp and Forth [2], but more in the Lisp camp, since it's so easy to write a metacircular evaluator [3] or a quine [4] in PostScript: {{[ exch /dup load /exec load ] cvx} dup exec} Do you remember Glenn Reid's "Distillery" [5]? It's a PostScript program that optimized other PostScript programs, which you prepended before your PostScript print file, sent to a printer, and it partially evaluated the PostScript code in the print file. It then echoed back another highly optimized flat PostScript program that printed the exact same pages, all in one coordinate system, with superfluous graphics state changes removed. That glorious hack, based on John Warnock's idea of redefining the imaging operators, eventually evolved into PDF! [6] Glenn also wrote a delightful "Font Appreciation" app for NeXT called TouchType [7], which decades later has only recently found its way into Photoshop. I wrote a visual interactive PostScript debugging tool for NeWS called the PSIBER Space Deck [8], and the PseudoScientific Visualizer [9] for drawing PostScript data structures like NeWS object and class dictionaries or a network map of ARPANET IMPs, and a paper [10] about them. It was most useful for debugging itself, which was fortunate, since it was pretty buggy. I integrated the metacircular PostScript evaluator with the debugger, so you could single step through PostScript code, and draw graphics to visualize the program execution state. And I made my own NeWS distillery [11] "in the spirit of Glenn Reid's Distillery" ;), for making flat printable PostScript dumps of anything procedurally drawn on the screen, which I used for some of the illustrations in the paper [12]. [1] Thinking Forth: http://thinking-forth.sourceforge.net/ http://thinking-forth.sourceforge.net/ [2] PostScript -vs- Forth: http://donhopkins.com/home/code/ps-vs-forth.txt http://donhopkins.com/home/code/ps-vs-forth.txt [3] PostScript Metacircular Evaluator: http://donhopkins.com/home/code/ps.ps.txt http://donhopkins.com/home/code/ps.ps.txt [4] PostScript Quine: http://donhopkins.com/home/archive/news-tape/fun/quine/quine http://donhopkins.com/home/archive/news-tape/fun/quine/quine [5] Glenn Reid's PostScript Distillery: http://donhopkins.com/home/archive/postscript/newerstill.ps.txt http://donhopkins.com/home/archive/postscript/newerstill.ps.... [6] The Distiller Story: http://blogs.adobe.com/insidepdf/2007/11/the_distiller_story.html http://blogs.adobe.com/insidepdf/2007/11/the_distiller_story... [7] TouchType: https://ftp.nice.ch/peanuts/GeneralData/Usenet/news/1990/_CSN-90/comp-sys-next/1990/Jul/_BaNG-%234-meeting-review.html https://ftp.nice.ch/peanuts/GeneralData/Usenet/news/1990/_CS... [8] PSIBER Space Deck Demo: https://www.youtube.com/watch?v=iuC_DDgQmsM https://www.youtube.com/watch?v=iuC_DDgQmsM [9] Pseudo Scientific Visualizer Demo: https://www.youtube.com/watch?v=_fqCeuue5Ac https://www.youtube.com/watch?v=_fqCeuue5Ac [10] The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines: http://www.donhopkins.com/drupal/node/97 http://www.donhopkins.com/drupal/node/97 [11] NeWS Distillery: http://donhopkins.com/home/archive/news-tape/utilities/cyber/distill.ps.txt http://donhopkins.com/home/archive/news-tape/utilities/cyber... [12] Distilled PostScript PseudoScientific Visualization of Arpanet IMPS: http://donhopkins.com/home/archive/news-tape/documents/psiber/10.ps.txt http://donhopkins.com/home/archive/news-tape/documents/psibe...
zxv 11y ago
Speaking of interesting mid 80s window systems, there was a light weight window system developed by Stephen Uhler at Belcore. It is under 20K lines of C, and very easy to port. It is able to run over a serial line or a socket, in a few hundred K of RAM. Screenshot: http://www.hack.org/mc/mgr/images/mgrscreen.png http://www.hack.org/mc/mgr/images/mgrscreen.png More info: http://www.hack.org/mc/mgr/ http://www.hack.org/mc/mgr/ "MGR is to X as Unix is to Multix." -Dan Nachbar
- gattilorenz 11y ago
  I have recently ran it on Xenix, on a 386 system. Quite impressive, indeed.
- cmrdporcupine 11y ago
  This was ported to the Atari ST/TT in the early 90s, and I ran it there. And then for a while it was the only practical option on my early (pre 1.0) Linux because X11 drivers for my Trident video card were not done. Some neat ideas. Nice and minimalist.
- cm3 11y ago
  MGR never supported X clients, right?
  - kjs3 11y ago
    Correct...totally different way of looking at the problem.
  - rwmj 11y ago
    No. The cool thing about MGR was that you programmed it by sending terminal-like control codes to stdout. (I used to run MGR on Minix).
    - arethuza 11y ago
      Neat - even works that way for input as well: "MGR notifies a client program of an event by sending it an ASCII character string in a format specified by the client program."
cer314 11y ago
Just this morning I spoke of NeWS (for the first time in at least 20 years) to a colleague at work. Very strange to see this posting on HN in the same day... PostScript with classes... and input methods... seemed to be a very interesting way to model user-interfaces, and graphics rendering in general...
tracker1 11y ago
This just reminds me how much of a shame it is that the best option for a remote UI today is a localized browser, and the tools that go with it... Don't get me wrong, I think the browser/web is a great platform, and better than many other options that have come and gone, that said... It sucks that VNC, X11, and RDP are the best we have... though, I will admit RDP is pretty serviceable, X11 just seems too janky to work over a really remote connection... and VNC, well it works, but, sigh... I don't think that any remote application UI will really take over as everyone that might work on such a thing wants to gain a lock in with the goal of financial gain... so nothing really reaches a significant market share. This is the case were something that is great and libre/opensource would be better than a standard.
- twsted 11y ago
  > X11 just seems too janky to work over a really remote connection. Surely It is. But I cannot forget how magic it seemed in the 80s doing titan$ export DISPLAY=zeus:0.0; xeyes & over slow serial lines.
  - arethuza 11y ago
    I cringe to think that I used to use xhost to allow access from any client - don't think there were many firewalls on JANET so anybody could have been connecting to the Sun (later DEC Alpha) I used.
  - pantulis 11y ago
    And the next thing would be something like zeus$ xhost + ;)
  - gpvos 11y ago
    xmeltdown
    - DonHopkins 11y ago
      Jeremy Huxtable made the original "Big Brother" NeWS version of eyes [1], which inspired xeyes at SIGGRAPH '88 [2], and he also made the NeWS version of melt [3], in just 30 lines of code! My favorite OpenWindows demo was Pat Lashley's monaeyes [4], of course. And I made a fancy version of eyeball windows for The NeWS Toolkit [5] to show off its drag-n-drop and nested window management capabilities, where the eyeball was the window frame, and the iris was the client window, and you could split them in two, and even drag and drop eyes inside of each other, so that sub-eye window frame was reparented inside the moving super-eye client iris! The effect was very creepy and CPU intensive, and I could never quite talk the OPEN LOOK folks into adopting them into the standard. [1] http://donhopkins.com/home/archive/news-tape/fun/eye/eye.ps.txt http://donhopkins.com/home/archive/news-tape/fun/eye/eye.ps.... [2] http://www.x.org/archive/X11R7.5/doc/man/man1/xeyes.1.html http://www.x.org/archive/X11R7.5/doc/man/man1/xeyes.1.html [3] http://donhopkins.com/home/archive/news-tape/fun/melt/melt.ps.txt http://donhopkins.com/home/archive/news-tape/fun/melt/melt.p... [4] http://donhopkins.com/home/archive/NeWS/monaeyes.txt http://donhopkins.com/home/archive/NeWS/monaeyes.txt [5] http://donhopkins.com/home/archive/NeWS/eyes.ps.txt http://donhopkins.com/home/archive/NeWS/eyes.ps.txt
simula67 11y ago
This is the project the demise of which lead to Java : http://www.blinkenlights.com/classiccmp/javaorigin.html http://www.blinkenlights.com/classiccmp/javaorigin.html
- DonHopkins 11y ago
  Keep in mind that while extremely fascinating and enlightening and well worth reading, and how apt his comparison to the Gaza strip, that essay is from Patrick's own unique perspective, and he does not necessarily share all the same opinions as the dispassionate people for whom he recommended euthanasia. ;)
arethuza 11y ago
I used HyperNeWS for a few years on a project and had great fun with it (front end in PostScript/NeWS, back end in Common Lisp and plumbing in C). You could do some neat tricks - draw something in the graphical editor, copy it and paste it as the shape of a window (stack). Another thing you could do was log in through the PostScript shell to the server, navigate to your window (or anything else) and fiddle with it using standard PostScript 2D transforms. e.g. You could gradually rotate a terminal window, although I would never have done this to a colleague as they were using it, honest. I rather enjoyed working in PostScript although I believe there was a C to PostScript compiler built at one point (inevitably this being done in Glasgow it was called pdb for "pure dead brilliant"). Don't think there was much of a security model in NeWS so probably not a great fit for today's world but it was so much cooler than X.
mhandley 11y ago
NeWS was really cool. Back in 1987/88 I used an early release of NeWS for my final-year undergrad project. It was made a little more challenging by only having a photocopy of a pre-release of the documentation, that was missing all the diagrams. The model was really cool - completely different from X11, which is much more limited. With X, your app runs on the client and sends drawing commands to the display server. With NeWS, you can split your app arbitrarily between the client and the display server. The client simply extends the server by sending it postscript functions to locally interpret when asynchronous events happen. So you can write new widgets, and they run entirely on the display server so get really low latency, while the rest of the app is running remotely over a piece-of-wet-string network connection. You could be sitting in from of a display running a nice interactive GUI, with the app running in a different country or over a modem connection. At least you could if the application designer got it right. Getting the split of functionality between the client and server (and the communication between them) right was definitely more challenging than writing X apps, but the benefits were significant.
- arethuza 11y ago
  Speaking of documentation - it was rather cool that when you purchased a Sun at that time (or maybe it was when you purchased OpenWindows) you can a set of official Adobe PostScript books (blue/red/green?).
- mcguire 11y ago
  8 1/2, from Plan 9, used a similar architecture, IIRC, because of the smart terminals it was written for. Check out the editor Sam for an example; one side is ed++, the other is the GUI.
  - mveety 11y ago
    You mean the Blit terminal. The Plan 9 window managers use a different architecture that takes advantage of Plan 9's design. Both are from Rob Pike though so they look basically the same.
  - jonjacky 11y ago
david-given 11y ago
NeWS was lovely --- the application got to download custom logic via Postscript onto the display server and run it there, so you could run interactive applications quite comfortably on high-latency links. Proper MVC separation! Also, it had PizzaTool. http://www.donhopkins.com/home/catalog/images/pizzatool.gif http://www.donhopkins.com/home/catalog/images/pizzatool.gif Source code: http://www.donhopkins.com/home/code/pizzatool.ps.txt http://www.donhopkins.com/home/code/pizzatool.ps.txt I've always rather wondered why no open source NeWS clone never came along.
- arethuza 11y ago
  Do you think the forking off multiple processes to draw all of the toppings concurrently was premature optimisation? ;-) [Edit: I was pleasantly surprised at how readable that code is]
  - david-given 11y ago
    Possibly premature, definitely not optimisation... ...but I saw it running in real time, and it was actually pretty cool to see all the toppings appear (this was on a Sparc ELC-class machine, so it didn't have much grunt). Seamless dithering on the monochrome display, too. Also, the spinning the pizza was done by rotating the rendered bitmap. The inaccuracies meant that as you spun it, the toppings would all gradually blend into each other. I suppose that's realistic, in a way.
    - DonHopkins 11y ago
      I'm glad you had fun! Thanks for the mention. The point of PizzaTool was to be well commented example code for developers to read, that showed how to plug many different parts of The NeWS Toolkit together (thus all the drag-n-drop and threading and image transformation stuff). You're right, that was the best "melting" effect I could come up with, within the constraints of the PostScript imaging model. PizzaTool spins the pizza automatically, because I got tired of turning the image rotate tool in Stuart Marks' RasterRap by hand again and again to get that melting effect. I left it running over Christmas vacation, and it collapsed into an blob. But you can still add more toppings at any time while it's spinning! Here's a demo of spinning pizzas, dragging and dropping images between RasterRap and PizzaTool, and cleaning the pizza tray afterwards with a wave. Sorry about the bad video quality! https://www.youtube.com/watch?v=avJnpDKHxPY&feature=youtu.be&t=21m42s https://www.youtube.com/watch?v=avJnpDKHxPY&feature=youtu.be...
mhd 11y ago
Ah, pie menus... Weirdly enough, the only place I see them these days is games.
- jle17 11y ago
  That may be due to Don Hopkins. He did the pie menus for NeWS and latter for The Sims.
  - shrizza 11y ago
    jwcad usage is very piemenu-centric.
agumonkey 11y ago
Maybe my google-fu was blurred by the 'news' term but it was very hard to find things about it (beside "NeWS was great").
baus 11y ago
NeWS wasn't the only windowing system to use Display PostScript. The other big one was NeXTSTEP which obviously became OS X.
- DonHopkins 11y ago
  NeWS was not actually Adobe's Display PostScript, but it was Sun's independent implementation and specialized dialect of PostScript, supporting light weight processes, overlapping arbitrarily shaped canvases, window management, event distribution, garbage collection, networking, object oriented programming, etc. The most important ability that NeWS had, but was missing from Display PostScript and its successors (OS/X Core Graphics, PDF, SVG, canvas API, etc), is the ability to download code to create an efficient custom high level application specific protocol between the client and server. That essential ability is what people call "AJAX" these days, now that PostScript has been supplanted by JavaScript and a whole bunch of different APIs, and now we're even downloading shaders to the GPU! Truly exciting! James Gosling chose PostScript from the start, for how its network programming ability dovetails with its graphics and data representation, instead of nailing it onto the side of a bunch of different technologies as an afterthought. To quote the comparison from the wikipedia article: NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently: 1) used PostScript code instead of JavaScript for programming. 2) used PostScript graphics instead of DHTML and CSS for rendering. 3) used PostScript data instead of XML and JSON for data representation.
  - DonHopkins 11y ago
    Here's a deeper discussion of the technical design differences between NeWS and Display PostScript, from a discussion with Robin Schaufler and James Gosling: From: James Gosling <jag@Sun.COM> Subject: Re: Display PS vs NeWS Date: 22 December 1988 at 19:35:08 GMT+1 To: Robin Schaufler <robin@Sun.COM> Cc: don@brillig.umd.edu (Don Hopkins), sevans%norquay@Sun.COM Robin: Don, I'm replying just to you, not to NeWS-makers (trying to stay out of trouble). The one major area where NeWS cannot emulate Display PS is that of memory management. Display PS introduces the notion of spaces; effectively, each process group gets its own heap. Kill the process group - the memory gets cleaned up whether it has cycles in it or not. Very nice, actually. But a major project for us if we decide to adopt it. Fortunately, we already started on a new memory management system for data localization that will help some with implementation. James: The thing that we don't have is a thousand caveats on what can be assigned to what. You can't have pointers that cross spaces in Adobe's scheme, so as you read through their documentation you find zillions of restrictions that make life very difficult. Also, the "kill the process group..." doesn't really apply: they don't have process groups. Each process is alone. If you want to share, you have to stick stuff in the "shared" space or be forked from a common parent. save/restore has bizarre semantics in this memory model: eg. if a process executes "save" then any other process that shares the same storage pool is blocked (honest, I'm not making this up!) Robin: We also can't emulate their lock mechanism. I had the distinct impression that they analysed NeWS monitors completely, figured out exactly what was wrong with them, and fixed it. I really like this extension, but again, considerable work for us (tho less than for the memory management extension). James: Far from considerable work and of dubious value: almost no one has ever used locks. DPS locks are identical to NeWS monitors (they're even applied with the same primitive "monitor"). NeWS is missing condition variables, which are a good idea but not difficult to implement. Events are the common form of process syncronization in NeWS. Robin: Another area we would have trouble emulating is their new halftoning operators, but that seems like less of a problem. The new operators allow for tiling, which we've implemented for X, but we'd still have to hook it up for NeWS, and provide their model, which isn't quite the same model. Actually, NeWS probably can emulate it but it would be beastly slow. James: Actually, the DPS threshhold are NOT the tiling operators that PostScript so badly needs. If you read it carefully, for devices with more than one bit per pixel you can't get the tiling effect. Halftones continue to only be useful for halftoning. Robin: In a few cases they picked the same names and operator spec as us, but in general they didn't try to be compatible. A few incompatibilities seem gratuitious to me. James: eg. processes
grymoire1 11y ago
I used and wrote code for NeWS - the pre-curser for Java. I was also at the talk where Gosling admitted the problems it had. In some cases, a lot of features of Java were in response to the problems with NeWS. NeWS was so awesome when it came out, where you can dynamically change the interface at any time. But NeWS had some horrible bits. As a language, it was very hard to read. If you saw a name, you didn't know if it was a variable or a function. That is, you didn't know if the value would be pushed onto the stack, or if it would pop some values off the stack. Best Practice was to add a comment after each line to indicate what the top of the stack would look like after that line. So if you got lost reading one line, you could figure out what the next line would do. But without it, after seeing three words in a row that you didn't fully understand, you were hopelessly lost. NeWS (PostScript) was a write-only display model. You could not remove anything painted on the screen. You had to write over it. Adobe had Display PostScript, but that never took off. And because of the write-only display, NeWS had a hard time freeing resources. Garbage collection was very difficult because of this. You would allocate a white square, and never truly "remove it" from memory. As I recall, a page refresh had to re-interpret all of the code - there wasn't any caching of the window. Also - the entire display model with postscript-based scaling was CPU intensive, especially if you had a computer with slow graphics (quite common at the time).
- DonHopkins 11y ago
  PostScript uses an immediate mode state machine, kind of like GL, but a lot simpler. So there is a "graphics state", and while it contains a reference to the current font and accumulates a path as you draw it, there was nothing like a display list or object oriented graphics that would remember to draw a square and never get garbage collected. Laser printers typically had a linear heap based memory allocation system that let you ensconce and roll back all modifications on a page with save/restore, but NeWS never used that for anything practical (although it did support it in a weird inefficient way of recording and reverting all mutations, which was more for backwards compatibility so the PostScript previewer could rendering existing PostScript documents that used save/restore, and never used in any interactive user interface toolkit or app outside a PostScript previewer). Instead of a heap like a laser printer, NeWS used a reference counting garbage collection system, so once all references to an object were gone, it and any non-reachable sub-objects would be destroyed. To work around problem of circular references leaking memory, later versions of NeWS supported soft reference counts: each object would have both a soft and a hard reference count, and you could soften a reference if you wanted to hold onto an object but be notified when it was no longer otherwise accessible. Once all the hard references to an object went away, if the soft reference count was still not yet zero, it sent out a /Destroy event on that object which anyone holding a soft reference to it must be listening for, and they clean up their reference in response to, and it's only deleted once its soft reference count goes to zero. It's a weak reference [2], but it used NeWS's built-in event distribution system to notify reference holders (since there was no way of PostScript code to hook into the destroy callback of an arbitrary dictionary). Needing to use soft references directly wasn't very common in ordinary NeWS programming, and most uses were wrapped up behind the scenes by the toolkit (like the selection service listening for the selected object to be destroyed, text fields and menus pointing at each other for focus and pinned menu management, etc). NeWS canvases could have a backing store that you could enable or disable, and they could be retained off screen, and top level windows were usually retained. Technically it was just a hint and you always had to be prepared to repaint in response to a /Damage event, but all servers supported retained canvases, and it still made sense to turn off retained mode in the case of simple efficient graphics on 24 bit color displays. The art was in coming up with simple efficient ways of representing the data and generating the code doing the drawing in the server, so it could draw as fast as possible. Cool things were possible by dynamically generating PostScript code with inlined numbers, colors, fonts and other invariant parameters, in response to window resizing or layout changes and higher level data. You could inline calculated values into stupid-but-fast specialized instance methods (NeWS used a prototype based object system, that let you promote methods into instances), by using the PostScript equivalent of Lisp's "backquote" macro. [2] [1] Weak References: https://en.wikipedia.org/wiki/Weak_reference https://en.wikipedia.org/wiki/Weak_reference [2] TNT Slider Design Document: using PostScript "backquote" macro to cache efficient rendering code: http://donhopkins.com/home/archive/NeWS/tnt-sliders-design-2.txt http://donhopkins.com/home/archive/NeWS/tnt-sliders-design-2...
mozumder 11y ago
OpenLook window manager was great.. I loved how customizable it was, using things like text files to customize root menus. It was also the best looking WM I've used.
grymoire1 11y ago
I used and wrote code for NeWS - the pre-curser for Java. I was also at the talk where Gosling admitted the problems it had. In some cases, a lot of features of Java were in response to the problems with NeWS. NeWS was so awesome when it came out, where you can dynamically change the interface at any time. But NeWS had some horrible bits. As a language, it was very hard to read. If you saw a name, you didn't know if it was a variable or a function. That is, you didn't know if the value would be pushed onto the stack, or if it would pop some values off the stack. Best Practice was to add a comment after each line to indicate what the top of the stack would look like after that line. So if you got lost reading one line, you could figure out what the next line would do. But without it, after seeing three words in a row that you didn't fully understand, you were hopelessly lost. NeWS (PostScript) was a write-only display model. You could not remove anything painted on the screen. You had to write over it. Adobe had Display PostScript, but that never took off. And because of the write-only display, NeWS had a hard time freeing resources. Garbage collection was very difficult because of this. You would allocate a white square, and never truly "remove it" from memory. As I recall, a page refresh had to re-interpret all of the code - there wasn't any caching of the window. Also - the entire display model with postscript-based scaling was CPU intensive, especially if you had a computer with slow graphics (quite common at the time).

86 points by stevewilhelm 11y ago

PostScript really is a lovely programming language. Some 20 years ago, I used a development environment (PSAlter) that made it quite palatable -- visualising dictionaries and stacks -- and made it possible to step through programs. There exists a nice free e-book describing PostScript (Thinking in PostScript by Glenn C. Reid) [1]. [1] https://web.archive.org/web/20000914161447/http://www.rightbrain.com/download/books/ThinkingInPostScript.pdf https://web.archive.org/web/20000914161447/http://www.rightb... EDIT While looking for the Thinking in PostScript book mentioned above, I stumbled upon this legal online archive for books on the net [2] which may be of interest to others. [2] http://onlinebooks.library.upenn.edu http://onlinebooks.library.upenn.edu

tonyedgecombe 11y ago
PSAlter is still available: http://www.quite.com/psalter/psalter.htm#order http://www.quite.com/psalter/psalter.htm#order
DonHopkins 11y ago
That's very cool! I'd like to see more about how the debugger works. Are there any video demos available, please? I love Glenn Reid's book, Thinking PostScript. It's like the Thinking Forth [1] of PostScript! ;) I always thought of PostScript as a cross between Lisp and Forth [2], but more in the Lisp camp, since it's so easy to write a metacircular evaluator [3] or a quine [4] in PostScript: {{[ exch /dup load /exec load ] cvx} dup exec} Do you remember Glenn Reid's "Distillery" [5]? It's a PostScript program that optimized other PostScript programs, which you prepended before your PostScript print file, sent to a printer, and it partially evaluated the PostScript code in the print file. It then echoed back another highly optimized flat PostScript program that printed the exact same pages, all in one coordinate system, with superfluous graphics state changes removed. That glorious hack, based on John Warnock's idea of redefining the imaging operators, eventually evolved into PDF! [6] Glenn also wrote a delightful "Font Appreciation" app for NeXT called TouchType [7], which decades later has only recently found its way into Photoshop. I wrote a visual interactive PostScript debugging tool for NeWS called the PSIBER Space Deck [8], and the PseudoScientific Visualizer [9] for drawing PostScript data structures like NeWS object and class dictionaries or a network map of ARPANET IMPs, and a paper [10] about them. It was most useful for debugging itself, which was fortunate, since it was pretty buggy. I integrated the metacircular PostScript evaluator with the debugger, so you could single step through PostScript code, and draw graphics to visualize the program execution state. And I made my own NeWS distillery [11] "in the spirit of Glenn Reid's Distillery" ;), for making flat printable PostScript dumps of anything procedurally drawn on the screen, which I used for some of the illustrations in the paper [12]. [1] Thinking Forth: http://thinking-forth.sourceforge.net/ http://thinking-forth.sourceforge.net/ [2] PostScript -vs- Forth: http://donhopkins.com/home/code/ps-vs-forth.txt http://donhopkins.com/home/code/ps-vs-forth.txt [3] PostScript Metacircular Evaluator: http://donhopkins.com/home/code/ps.ps.txt http://donhopkins.com/home/code/ps.ps.txt [4] PostScript Quine: http://donhopkins.com/home/archive/news-tape/fun/quine/quine http://donhopkins.com/home/archive/news-tape/fun/quine/quine [5] Glenn Reid's PostScript Distillery: http://donhopkins.com/home/archive/postscript/newerstill.ps.txt http://donhopkins.com/home/archive/postscript/newerstill.ps.... [6] The Distiller Story: http://blogs.adobe.com/insidepdf/2007/11/the_distiller_story.html http://blogs.adobe.com/insidepdf/2007/11/the_distiller_story... [7] TouchType: https://ftp.nice.ch/peanuts/GeneralData/Usenet/news/1990/_CSN-90/comp-sys-next/1990/Jul/_BaNG-%234-meeting-review.html https://ftp.nice.ch/peanuts/GeneralData/Usenet/news/1990/_CS... [8] PSIBER Space Deck Demo: https://www.youtube.com/watch?v=iuC_DDgQmsM https://www.youtube.com/watch?v=iuC_DDgQmsM [9] Pseudo Scientific Visualizer Demo: https://www.youtube.com/watch?v=_fqCeuue5Ac https://www.youtube.com/watch?v=_fqCeuue5Ac [10] The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines: http://www.donhopkins.com/drupal/node/97 http://www.donhopkins.com/drupal/node/97 [11] NeWS Distillery: http://donhopkins.com/home/archive/news-tape/utilities/cyber/distill.ps.txt http://donhopkins.com/home/archive/news-tape/utilities/cyber... [12] Distilled PostScript PseudoScientific Visualization of Arpanet IMPS: http://donhopkins.com/home/archive/news-tape/documents/psiber/10.ps.txt http://donhopkins.com/home/archive/news-tape/documents/psibe...

zxv 11y ago

Speaking of interesting mid 80s window systems, there was a light weight window system developed by Stephen Uhler at Belcore. It is under 20K lines of C, and very easy to port. It is able to run over a serial line or a socket, in a few hundred K of RAM. Screenshot: http://www.hack.org/mc/mgr/images/mgrscreen.png http://www.hack.org/mc/mgr/images/mgrscreen.png More info: http://www.hack.org/mc/mgr/ http://www.hack.org/mc/mgr/ "MGR is to X as Unix is to Multix." -Dan Nachbar

gattilorenz 11y ago
I have recently ran it on Xenix, on a 386 system. Quite impressive, indeed.
cmrdporcupine 11y ago
This was ported to the Atari ST/TT in the early 90s, and I ran it there. And then for a while it was the only practical option on my early (pre 1.0) Linux because X11 drivers for my Trident video card were not done. Some neat ideas. Nice and minimalist.
cm3 11y ago
MGR never supported X clients, right?
- kjs3 11y ago
  Correct...totally different way of looking at the problem.
- rwmj 11y ago
  No. The cool thing about MGR was that you programmed it by sending terminal-like control codes to stdout. (I used to run MGR on Minix).
  - arethuza 11y ago
    Neat - even works that way for input as well: "MGR notifies a client program of an event by sending it an ASCII character string in a format specified by the client program."

cer314 11y ago

Just this morning I spoke of NeWS (for the first time in at least 20 years) to a colleague at work. Very strange to see this posting on HN in the same day... PostScript with classes... and input methods... seemed to be a very interesting way to model user-interfaces, and graphics rendering in general...

tracker1 11y ago

This just reminds me how much of a shame it is that the best option for a remote UI today is a localized browser, and the tools that go with it... Don't get me wrong, I think the browser/web is a great platform, and better than many other options that have come and gone, that said... It sucks that VNC, X11, and RDP are the best we have... though, I will admit RDP is pretty serviceable, X11 just seems too janky to work over a really remote connection... and VNC, well it works, but, sigh... I don't think that any remote application UI will really take over as everyone that might work on such a thing wants to gain a lock in with the goal of financial gain... so nothing really reaches a significant market share. This is the case were something that is great and libre/opensource would be better than a standard.

twsted 11y ago
> X11 just seems too janky to work over a really remote connection. Surely It is. But I cannot forget how magic it seemed in the 80s doing titan$ export DISPLAY=zeus:0.0; xeyes & over slow serial lines.
- arethuza 11y ago
  I cringe to think that I used to use xhost to allow access from any client - don't think there were many firewalls on JANET so anybody could have been connecting to the Sun (later DEC Alpha) I used.
- pantulis 11y ago
  And the next thing would be something like zeus$ xhost + ;)
- gpvos 11y ago
  xmeltdown
  - DonHopkins 11y ago
    Jeremy Huxtable made the original "Big Brother" NeWS version of eyes [1], which inspired xeyes at SIGGRAPH '88 [2], and he also made the NeWS version of melt [3], in just 30 lines of code! My favorite OpenWindows demo was Pat Lashley's monaeyes [4], of course. And I made a fancy version of eyeball windows for The NeWS Toolkit [5] to show off its drag-n-drop and nested window management capabilities, where the eyeball was the window frame, and the iris was the client window, and you could split them in two, and even drag and drop eyes inside of each other, so that sub-eye window frame was reparented inside the moving super-eye client iris! The effect was very creepy and CPU intensive, and I could never quite talk the OPEN LOOK folks into adopting them into the standard. [1] http://donhopkins.com/home/archive/news-tape/fun/eye/eye.ps.txt http://donhopkins.com/home/archive/news-tape/fun/eye/eye.ps.... [2] http://www.x.org/archive/X11R7.5/doc/man/man1/xeyes.1.html http://www.x.org/archive/X11R7.5/doc/man/man1/xeyes.1.html [3] http://donhopkins.com/home/archive/news-tape/fun/melt/melt.ps.txt http://donhopkins.com/home/archive/news-tape/fun/melt/melt.p... [4] http://donhopkins.com/home/archive/NeWS/monaeyes.txt http://donhopkins.com/home/archive/NeWS/monaeyes.txt [5] http://donhopkins.com/home/archive/NeWS/eyes.ps.txt http://donhopkins.com/home/archive/NeWS/eyes.ps.txt

simula67 11y ago

This is the project the demise of which lead to Java : http://www.blinkenlights.com/classiccmp/javaorigin.html http://www.blinkenlights.com/classiccmp/javaorigin.html

DonHopkins 11y ago
Keep in mind that while extremely fascinating and enlightening and well worth reading, and how apt his comparison to the Gaza strip, that essay is from Patrick's own unique perspective, and he does not necessarily share all the same opinions as the dispassionate people for whom he recommended euthanasia. ;)

arethuza 11y ago

I used HyperNeWS for a few years on a project and had great fun with it (front end in PostScript/NeWS, back end in Common Lisp and plumbing in C). You could do some neat tricks - draw something in the graphical editor, copy it and paste it as the shape of a window (stack). Another thing you could do was log in through the PostScript shell to the server, navigate to your window (or anything else) and fiddle with it using standard PostScript 2D transforms. e.g. You could gradually rotate a terminal window, although I would never have done this to a colleague as they were using it, honest. I rather enjoyed working in PostScript although I believe there was a C to PostScript compiler built at one point (inevitably this being done in Glasgow it was called pdb for "pure dead brilliant"). Don't think there was much of a security model in NeWS so probably not a great fit for today's world but it was so much cooler than X.

mhandley 11y ago

NeWS was really cool. Back in 1987/88 I used an early release of NeWS for my final-year undergrad project. It was made a little more challenging by only having a photocopy of a pre-release of the documentation, that was missing all the diagrams. The model was really cool - completely different from X11, which is much more limited. With X, your app runs on the client and sends drawing commands to the display server. With NeWS, you can split your app arbitrarily between the client and the display server. The client simply extends the server by sending it postscript functions to locally interpret when asynchronous events happen. So you can write new widgets, and they run entirely on the display server so get really low latency, while the rest of the app is running remotely over a piece-of-wet-string network connection. You could be sitting in from of a display running a nice interactive GUI, with the app running in a different country or over a modem connection. At least you could if the application designer got it right. Getting the split of functionality between the client and server (and the communication between them) right was definitely more challenging than writing X apps, but the benefits were significant.

arethuza 11y ago
Speaking of documentation - it was rather cool that when you purchased a Sun at that time (or maybe it was when you purchased OpenWindows) you can a set of official Adobe PostScript books (blue/red/green?).
mcguire 11y ago
8 1/2, from Plan 9, used a similar architecture, IIRC, because of the smart terminals it was written for. Check out the editor Sam for an example; one side is ed++, the other is the GUI.
- mveety 11y ago
  You mean the Blit terminal. The Plan 9 window managers use a different architecture that takes advantage of Plan 9's design. Both are from Rob Pike though so they look basically the same.
- jonjacky 11y ago

david-given 11y ago

NeWS was lovely --- the application got to download custom logic via Postscript onto the display server and run it there, so you could run interactive applications quite comfortably on high-latency links. Proper MVC separation! Also, it had PizzaTool. http://www.donhopkins.com/home/catalog/images/pizzatool.gif http://www.donhopkins.com/home/catalog/images/pizzatool.gif Source code: http://www.donhopkins.com/home/code/pizzatool.ps.txt http://www.donhopkins.com/home/code/pizzatool.ps.txt I've always rather wondered why no open source NeWS clone never came along.

arethuza 11y ago
Do you think the forking off multiple processes to draw all of the toppings concurrently was premature optimisation? ;-) [Edit: I was pleasantly surprised at how readable that code is]
- david-given 11y ago
  Possibly premature, definitely not optimisation... ...but I saw it running in real time, and it was actually pretty cool to see all the toppings appear (this was on a Sparc ELC-class machine, so it didn't have much grunt). Seamless dithering on the monochrome display, too. Also, the spinning the pizza was done by rotating the rendered bitmap. The inaccuracies meant that as you spun it, the toppings would all gradually blend into each other. I suppose that's realistic, in a way.
  - DonHopkins 11y ago
    I'm glad you had fun! Thanks for the mention. The point of PizzaTool was to be well commented example code for developers to read, that showed how to plug many different parts of The NeWS Toolkit together (thus all the drag-n-drop and threading and image transformation stuff). You're right, that was the best "melting" effect I could come up with, within the constraints of the PostScript imaging model. PizzaTool spins the pizza automatically, because I got tired of turning the image rotate tool in Stuart Marks' RasterRap by hand again and again to get that melting effect. I left it running over Christmas vacation, and it collapsed into an blob. But you can still add more toppings at any time while it's spinning! Here's a demo of spinning pizzas, dragging and dropping images between RasterRap and PizzaTool, and cleaning the pizza tray afterwards with a wave. Sorry about the bad video quality! https://www.youtube.com/watch?v=avJnpDKHxPY&feature=youtu.be&t=21m42s https://www.youtube.com/watch?v=avJnpDKHxPY&feature=youtu.be...

mhd 11y ago

Ah, pie menus... Weirdly enough, the only place I see them these days is games.

jle17 11y ago
That may be due to Don Hopkins. He did the pie menus for NeWS and latter for The Sims.
- shrizza 11y ago
  jwcad usage is very piemenu-centric.

agumonkey 11y ago

Maybe my google-fu was blurred by the 'news' term but it was very hard to find things about it (beside "NeWS was great").

baus 11y ago

NeWS wasn't the only windowing system to use Display PostScript. The other big one was NeXTSTEP which obviously became OS X.

DonHopkins 11y ago
NeWS was not actually Adobe's Display PostScript, but it was Sun's independent implementation and specialized dialect of PostScript, supporting light weight processes, overlapping arbitrarily shaped canvases, window management, event distribution, garbage collection, networking, object oriented programming, etc. The most important ability that NeWS had, but was missing from Display PostScript and its successors (OS/X Core Graphics, PDF, SVG, canvas API, etc), is the ability to download code to create an efficient custom high level application specific protocol between the client and server. That essential ability is what people call "AJAX" these days, now that PostScript has been supplanted by JavaScript and a whole bunch of different APIs, and now we're even downloading shaders to the GPU! Truly exciting! James Gosling chose PostScript from the start, for how its network programming ability dovetails with its graphics and data representation, instead of nailing it onto the side of a bunch of different technologies as an afterthought. To quote the comparison from the wikipedia article: NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently: 1) used PostScript code instead of JavaScript for programming. 2) used PostScript graphics instead of DHTML and CSS for rendering. 3) used PostScript data instead of XML and JSON for data representation.
- DonHopkins 11y ago
  Here's a deeper discussion of the technical design differences between NeWS and Display PostScript, from a discussion with Robin Schaufler and James Gosling: From: James Gosling <jag@Sun.COM> Subject: Re: Display PS vs NeWS Date: 22 December 1988 at 19:35:08 GMT+1 To: Robin Schaufler <robin@Sun.COM> Cc: don@brillig.umd.edu (Don Hopkins), sevans%norquay@Sun.COM Robin: Don, I'm replying just to you, not to NeWS-makers (trying to stay out of trouble). The one major area where NeWS cannot emulate Display PS is that of memory management. Display PS introduces the notion of spaces; effectively, each process group gets its own heap. Kill the process group - the memory gets cleaned up whether it has cycles in it or not. Very nice, actually. But a major project for us if we decide to adopt it. Fortunately, we already started on a new memory management system for data localization that will help some with implementation. James: The thing that we don't have is a thousand caveats on what can be assigned to what. You can't have pointers that cross spaces in Adobe's scheme, so as you read through their documentation you find zillions of restrictions that make life very difficult. Also, the "kill the process group..." doesn't really apply: they don't have process groups. Each process is alone. If you want to share, you have to stick stuff in the "shared" space or be forked from a common parent. save/restore has bizarre semantics in this memory model: eg. if a process executes "save" then any other process that shares the same storage pool is blocked (honest, I'm not making this up!) Robin: We also can't emulate their lock mechanism. I had the distinct impression that they analysed NeWS monitors completely, figured out exactly what was wrong with them, and fixed it. I really like this extension, but again, considerable work for us (tho less than for the memory management extension). James: Far from considerable work and of dubious value: almost no one has ever used locks. DPS locks are identical to NeWS monitors (they're even applied with the same primitive "monitor"). NeWS is missing condition variables, which are a good idea but not difficult to implement. Events are the common form of process syncronization in NeWS. Robin: Another area we would have trouble emulating is their new halftoning operators, but that seems like less of a problem. The new operators allow for tiling, which we've implemented for X, but we'd still have to hook it up for NeWS, and provide their model, which isn't quite the same model. Actually, NeWS probably can emulate it but it would be beastly slow. James: Actually, the DPS threshhold are NOT the tiling operators that PostScript so badly needs. If you read it carefully, for devices with more than one bit per pixel you can't get the tiling effect. Halftones continue to only be useful for halftoning. Robin: In a few cases they picked the same names and operator spec as us, but in general they didn't try to be compatible. A few incompatibilities seem gratuitious to me. James: eg. processes

grymoire1 11y ago

I used and wrote code for NeWS - the pre-curser for Java. I was also at the talk where Gosling admitted the problems it had. In some cases, a lot of features of Java were in response to the problems with NeWS. NeWS was so awesome when it came out, where you can dynamically change the interface at any time. But NeWS had some horrible bits. As a language, it was very hard to read. If you saw a name, you didn't know if it was a variable or a function. That is, you didn't know if the value would be pushed onto the stack, or if it would pop some values off the stack. Best Practice was to add a comment after each line to indicate what the top of the stack would look like after that line. So if you got lost reading one line, you could figure out what the next line would do. But without it, after seeing three words in a row that you didn't fully understand, you were hopelessly lost. NeWS (PostScript) was a write-only display model. You could not remove anything painted on the screen. You had to write over it. Adobe had Display PostScript, but that never took off. And because of the write-only display, NeWS had a hard time freeing resources. Garbage collection was very difficult because of this. You would allocate a white square, and never truly "remove it" from memory. As I recall, a page refresh had to re-interpret all of the code - there wasn't any caching of the window. Also - the entire display model with postscript-based scaling was CPU intensive, especially if you had a computer with slow graphics (quite common at the time).

DonHopkins 11y ago
PostScript uses an immediate mode state machine, kind of like GL, but a lot simpler. So there is a "graphics state", and while it contains a reference to the current font and accumulates a path as you draw it, there was nothing like a display list or object oriented graphics that would remember to draw a square and never get garbage collected. Laser printers typically had a linear heap based memory allocation system that let you ensconce and roll back all modifications on a page with save/restore, but NeWS never used that for anything practical (although it did support it in a weird inefficient way of recording and reverting all mutations, which was more for backwards compatibility so the PostScript previewer could rendering existing PostScript documents that used save/restore, and never used in any interactive user interface toolkit or app outside a PostScript previewer). Instead of a heap like a laser printer, NeWS used a reference counting garbage collection system, so once all references to an object were gone, it and any non-reachable sub-objects would be destroyed. To work around problem of circular references leaking memory, later versions of NeWS supported soft reference counts: each object would have both a soft and a hard reference count, and you could soften a reference if you wanted to hold onto an object but be notified when it was no longer otherwise accessible. Once all the hard references to an object went away, if the soft reference count was still not yet zero, it sent out a /Destroy event on that object which anyone holding a soft reference to it must be listening for, and they clean up their reference in response to, and it's only deleted once its soft reference count goes to zero. It's a weak reference [2], but it used NeWS's built-in event distribution system to notify reference holders (since there was no way of PostScript code to hook into the destroy callback of an arbitrary dictionary). Needing to use soft references directly wasn't very common in ordinary NeWS programming, and most uses were wrapped up behind the scenes by the toolkit (like the selection service listening for the selected object to be destroyed, text fields and menus pointing at each other for focus and pinned menu management, etc). NeWS canvases could have a backing store that you could enable or disable, and they could be retained off screen, and top level windows were usually retained. Technically it was just a hint and you always had to be prepared to repaint in response to a /Damage event, but all servers supported retained canvases, and it still made sense to turn off retained mode in the case of simple efficient graphics on 24 bit color displays. The art was in coming up with simple efficient ways of representing the data and generating the code doing the drawing in the server, so it could draw as fast as possible. Cool things were possible by dynamically generating PostScript code with inlined numbers, colors, fonts and other invariant parameters, in response to window resizing or layout changes and higher level data. You could inline calculated values into stupid-but-fast specialized instance methods (NeWS used a prototype based object system, that let you promote methods into instances), by using the PostScript equivalent of Lisp's "backquote" macro. [2] [1] Weak References: https://en.wikipedia.org/wiki/Weak_reference https://en.wikipedia.org/wiki/Weak_reference [2] TNT Slider Design Document: using PostScript "backquote" macro to cache efficient rendering code: http://donhopkins.com/home/archive/NeWS/tnt-sliders-design-2.txt http://donhopkins.com/home/archive/NeWS/tnt-sliders-design-2...

mozumder 11y ago

OpenLook window manager was great.. I loved how customizable it was, using things like text files to customize root menus. It was also the best looking WM I've used.

grymoire1 11y ago