X and NeWS history

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.