John Steinhart is outstanding in his field!
Sometimes he's even out driving a tractor in his field! ;)
replies(1):
Sometimes he's even out driving a tractor in his field! ;)
NeWS 1.1 was layered on top of PixRects (the graphics library that SunView was built on top of), which gave it the weird limitation that sub-windows could not be positioned above or to the left of their parents (sub-window coordinates were unsigned), which was a huge pain in the ass for making all kinds of user interfaces.
X11/NeWS solved that problem by having a much nicer PostScript graphics renderer and compositor, but it came with its own set of problems, many having to do with being nailed together with a X11 server with a totally different graphics model and approach to life.
But there were some really cool things you could do with X11 and NeWS together, like managing X11 windows with NeWS frames (which could have non-rectangular windows like jutting title tabs, round pie menus, panning virtual desktops, rooms, etc).
Another important point is that running the window manager in the same heavy weight Unix process as the window server saves an astronomical number of costly context switches, and results in much smoother user interface with silky local feedback. Plus it's extensible and customizable and drawn in PostScript.
Here's a demo of NeWS window frames with tabs and pie menus. We used those to made an ICCCM X11 window manager written in PostScript (that Sun never released) that let you use those tabbed window frames and pie menus and other NeWS components to manage all of your X11 windows (and use them as your default frame for NeWS apps too, of course), seamlessly integrating X11 and NeWS apps together.
https://www.youtube.com/watch?v=tMcmQk-q0k4
Here are some flames and notes I wrote years ago about X11 and NeWS window management -- the "OWM" section is about the NeWS X11 window manager. It covers some of the political and technical problems we had integrating X11 and NeWS. Window management is a surprisingly contentious issue! Everybody wants to be on top.
http://www.donhopkins.com/home/catalog/unix-haters/x-windows...
Basically, we didn't want to put our round NeWS pie menus and pizza windows inside of their rectangular X11 ICCCM window frames, because it would have been better for everyone the other way around.
http://www.donhopkins.com/home/catalog/images/pizzatool.gif
Josh Siegel wrote this beautiful PostScript tour de force swan song for X11/NeWS, an ICCCM window manager that actually worked quite well, with special window subclasses to support all the OPEN LOOK dialog types and window frame features through their standard X11 ICCCM properties! Check out "ClassX11ManagerMixin", which is what it sounds like. It's mixed into FavoriteBaseWindow, which can be redefined to the custom ClassTabBaseWindow supporting tabs and pie menus, shown in the above video, or any other kind of frame you want to wrap around X11 windows:
http://www.donhopkins.com/home/archive/NeWS/owm.ps.txt
It was a proof of concept, which we wanted to take a lot further by implementing a HyperCard-like user customizable persistent window manager with HyperLook. So users can edit and build their own custom window frames by copying, pasting and configuring scriptable components from object warehouses, edit and extend the user interfaces of running apps, and make high level task-oriented interfaces by composing widgets and apps into "cards", "backgrounds", "stacks" and optional network "clients". But that's not how things turned out. ;/
http://www.donhopkins.com/home/catalog/hyperlook/index.html
http://www.donhopkins.com/home/catalog/hyperlook/Warehouse1....
http://www.donhopkins.com/home/catalog/hyperlook/ButtonIdeas...
http://www.donhopkins.com/home/catalog/hyperlook/TalkInterfa...
http://www.donhopkins.com/home/catalog/hyperlook/TalkRunTime...
I'll excerpt the relevant parts of the i39l flames:
Who Should Manage the Windows, X11 or NeWS?
This is a discussion of ICCCM Window Management for X11/NeWS. One of the horrible problems of X11/NeWS was window management. The X people wanted to wrap NeWS windows up in X frames (that is, OLWM). The NeWS people wanted to do it the other way around, and prototyped an ICCCM window manager in NeWS (mostly object oriented PostScript, and a tiny bit of C), that wrapped X windows up in NeWS window frames.
Why wrap X windows in NeWS frames? Because NeWS is much better at window management than X. On the surface, it was easy to implement lots of cool features. But deeper, NeWS is capable of synchronizing input events much more reliably than X11, so it can manage the input focus perfectly, where asynchronous X11 window managers fall flat on their face by definition.
Our next step (if you'll pardon the allusion) was to use HyperNeWS (renamed HyperLook, a graphical user interface system like HyperCard with PostScript) to implemented a totally customizable X window manager!
Some notes about OWM
OWM is the "Open Window Manager" we prototyped in NeWS. We enhanced the NeWS window frames so they sported indexing tabs, pie menus, rooms, and a scrolling virtual desktop. Many of our enhancements were separatly developed, and plugged together orthogonally like legos. All NeWS applications could use these fancy frames, and the Open Window Manager wrapped X clients in the same frames that NeWS windows got!
This way, factoring the window frames out as a part of the toolkit, and implementing the X window manager separately, NeWS applications don't have to know a thing about X window management, and X clients can go on doing the same nasty things they've always done, and everybody get the benefits of dynamic extensibility, and a consistent user interface, by using the default window class!
X11 window managers must grab the server in order to animate rubber-band feedback over the screen when resizing and moving windows. This grabbing causes many problems with NeWS synchronous interests, that can be demonstrated by pressing the "Help" key while dragging out a rectangle on the root background. NeWS can do a much better job at managing global resources in the server because it is in the same address space and it has facilities like the overlay plane specifically designed to implement such window management functions, without even grabbing the server. This antisocial server grabbing behavior is just one symptom of a general class of problems with external X window management, including other important issues such as keyboard and colomap focus.
I wonder how the comparison between X11 & NeWS works once when switches to tiling window managers, which require much less work & chrome from the WM.
If tiling WMs favour the X model, I wonder if the real reason so many of us like them is that they are faster, rather than tiling being a better paradigm. I suspect that's not the case — at this point, tiling really feels better to me — but maybe it is?
Having an extensible window server enables you to use simpler but powerful primitives (X windows -vs- NeWS canvases, or server grabs + XOR RasterOps -vs- overlay canvases and hardware overlay planes), then implement the higher level stuff flexibly in software: see my other message about the complexity of X window borders, backgrounds and shapes, and how it makes shaped windows unbelievably complicated, even though nobody actually ever needs to use that complexity.
NeWS canvases don't need special built-in borders, because the PostScript interpreter and stencil-paint graphics model's clipping path elegantly solves the problem that X window borders were trying to solve (but didn't solve well enough for anyone to ever use), and solve many more problems in a much more general way.
NeWS had an overlay canvas for non-destructively drawing rubber band feedback over the desktop, which used hardware graphics planes if available, or fell back to using a display list and XOR RaserOps on monochrome or simple 8 bit displays.
Some of the popular Sun color framebuffers (cgsix and gx maybe?) had 8 bits of color pixles and a two bits of overlay planes for cursors and black-and-white windows. SunView knew how to use it for the cursor and light weight monochrome windows, and NeWS used it for the overlay plane, which was perfect for window management and rubber band feedback.
Drawing the cursor in the overlay plane actually sped up graphics performance a surprising amount, since the drawing code didn't have to always check if the cursor was overlapping where it was about to draw, then hiding and redrawing it before and after drawing anything on the screen under the cursor.
NeWS could directly open framebuffers on the overlay plane (1 bit black and white) and overlay enable plane (1 bit that switches between the showing the black and white overlay plane, or showing through to the color framebuffer). Then you could draw on the overlay enable plane to flip between the black and white and color framebuffers on a per-pixel bases (useful for making rubber bands, text labels, 50% checkerboard shadows and highlights, etc).
SGI's 4Sight (their own port of NeWS 1.1 that they integrated with X11 and GL, before Sun's X11/NeWS) also supported hardware overlay planes, and used them for the pop-up menus, so it didn't have to repaint the thick 24 bit graphics underneath the thin monochrome menus when they popped down. My NeWS pie menu code "just worked" in the overlay plane with only a little modification, except that I had to special-case the color wheel pie menu to not use the overlay plane, because the overlay planes weren't allowed more than three colors (black, white, one user defined color, and transparent).
If you're into the history of window management, here's some fascinating stuff about the evolution of window managers, including Andrew, which is a tiling window manager that Gosling and Rosenthal worked on at CMU before NeWS. It also discusses and compares PERQ PNX, APOLLO, SunWindows, MG-1, Sapphire, BLIT, Smalltalk, DLISP, Interlisp-D, Tajo/Mesa, Cedar Docs and Viewers, Star, Viewpoint, and even SunDew (NeWS).
"Methodology of Window Management": http://www.chilton-computing.org.uk/inf/literature/books/wm/...
By F R A Hopgood, D A Duce, E V C Fielding, K Robinson, A S Williams. 29 April 1985. This is the Proceedings of the Alvey Workshop at Cosener's House, Abingdon that took place from 29 April 1985 until 1 May 1985. It was input into the planning for the MMI part of the Alvey Programme. The Proceedings were later published by Springer-Verlag in 1986.
My favorite chapters:
"A Comparison of Some Window Managers" by Tony Williams: http://www.chilton-computing.org.uk/inf/literature/books/wm/...
"Ten Years of Window Systems - A Retrospective View" by Warren Teitelman: http://www.chilton-computing.org.uk/inf/literature/books/wm/...
"SunDew - A Distributed and Extensible Window System" by Games Gosling: http://www.chilton-computing.org.uk/inf/literature/books/wm/...
"User Interface Working Group Discussions": http://www.chilton-computing.org.uk/inf/literature/books/wm/...
"User Interface Working Group Final Report": http://www.chilton-computing.org.uk/inf/literature/books/wm/...
Here is some of the ui working group discussion specifically about tiling windows:
17.2 INTERFACE TECHNIQUES
Some of the issues supplied to the Working Group were felt not to be issues at all; as an example, tiled and overlapped windows were seen to be merely options that the user interface designer could use if appropriate. Indeed, a user connected to more than one host, one providing a tiling environment and the other not. might well have both mechanisms to interact with at the same time.
Window grouping and subwindows received some attention. A subwindow is not necessarily identical to a window: for example a subwindow receiving input it does not understand refers it to the parent for treatment, and if a parent window is deleted then so are its subwindows. Subwindows in some systems can overlap. while others permit only tiling. Title lines, which can be considered as a form of subwindow. may need to be accessible to the application.
