
X and NeWS history - colinprince
http://minnie.tuhs.org/pipermail/tuhs/2017-September/010471.html
======
jandrese
The comment about how X is really just a distributed database system with
occasional visual side effects that could be reduced down to 10 or so API
calls gives us a glimpse as to what life could have been.

It's a shame that all of the X replacements on the horizon also ditch the
network transparency part, even though that's been a killer feature for me. I
hate how much of a hack Remote Desktop is on Windows machines.

~~~
JoshTriplett
> It's a shame that all of the X replacements on the horizon also ditch the
> network transparency part, even though that's been a killer feature for me.

I've used ssh -X many times in my life, but at the same time, I understand why
network transparency doesn't make as much sense anymore.

Classically, the X protocol kept a huge amount of state on the server, and
clients would just send small requests to manipulate that data. Drawing would
take place server-side, and it was relatively simple drawing at that, since UI
needs were fairly modest. Text rendering occurred on the server with small
strings sent from the client. And overall, it made sense to send a small
amount of data to produce a large amount of graphics.

These days, however, rendering occurs almost exclusively on a combination of
the client and the GPU. Everything takes place via large memory buffers, and
compositing. And pushing those over the wire doesn't work nearly as well; if
you're going to do that, you need protocols designed for it, with compression
and delta-encoding, much like modern video codecs (but optimized for remote-
desktop).

So I think it makes sense that network transparency is being rethought, in
favor of protocols that look a lot more like remote-video (and remote-audio).

~~~
lscotte
People not familiar with X reading the above (which is correct) might miss
that client/server is reversed from the way most people think about it. For X,
the server is the system where the display/keyboard/UI is physically attached
and the client is the host (remote host for this discussion) where the
application is actually running.

~~~
asveikau
I don't know why this is confusing to people, at least if they understand
sockets. The display server does listen(2). The application does connect(2).
Why is that hard?

Windows and Mac use similar terminology to "display server" too, but I guess
those are proprietary components that few people look into...

~~~
sjwright
I understand sockets and I understand how X works, and I think it's confusing
and stupid. It places unnecessary emphasis on an implementation detail that is
unimportant to the end user.

~~~
asveikau
Then say "app" or "program" instead of "x client" and nobody is harmed ... If
people say "x client" it's usually in a more architectural, less colloquial
context to begin with.

------
DonHopkins
"Had he done some real design work and looked at what others were doing he
might have realized that at its core, X was a distributed database system in
which operations on some of the databases have visual side-effects. I forget
the exact number, but X includes around 20 different databases: atoms,
properties, contexts, selections, keymaps, etc. each with their own set of API
calls. As a result, the X API is wide and shallow like the Mac, and full of
interesting race conditions to boot. The whole thing could have been done with
less than a dozen API calls."

To that end, one of the weirder and cooler re-implementations of NeWS was
Cogent's PIX for transputers. It was basically a NeWS-like multiprocessing
PostScript interpreter for Transputers, with Linda "tuple spaces" as an
interprocess communication primitive:

[http://ieeexplore.ieee.org/document/301904/](http://ieeexplore.ieee.org/document/301904/)

The Cogent Research XTM is a desktop parallel computer based on the INMOS T800
transputer. Designed to expand from two to several hundred processors, the XTM
provides a transparent distributed computing environment both within a single
workstation and among a collection of workstations. Using Linda tuple spaces
as the basis for interprocess communication and synchronization, a Unix-
compatible, server-based OS was constructed. A graphic user interface is
provided by an interactive PostScript window server called PIX. All processors
see the same set of system services, and within protection limits, programs
capable of using many processors can spread out over a network of workstations
and resource servers, acquiring the services of unused processors.

[http://wiki.c2.com/?TupleSpace](http://wiki.c2.com/?TupleSpace)

[https://en.wikipedia.org/wiki/Tuple_space](https://en.wikipedia.org/wiki/Tuple_space)

------
wwweston
> I have a section in the book that I'm writing where I talk about how to
> design a good API. I pose the question of why none of the original Apple Mac
> API published in 1985 taking about 1,200 pages is in use today whereas
> almost all of the UNIX V6 API published in 1975 taking 321 pages is still in
> use and has been copied by many other systems. I'm sure that everyone on
> this list knows the answer.

I'm not sure I do. But it does seem like a good question.

Also:

[http://www.art.net/~hopkins/Don/unix-
haters/x-windows/disast...](http://www.art.net/~hopkins/Don/unix-
haters/x-windows/disaster.html)

~~~
valuearb
My guess is that the original Mac OS provided a great GUI, but not much of an
OS. It loaded a single application at a time that had access to all of memory.
That's why it had desk accessories, to give you apps you could use without
quitting the main application. It had handle based memory management so the OS
could move memory blocks more contagiously to create enough open space for new
memory allocations.

Over time they added cooperative multitasking, which meant the foreground app
had to consciously give time to let background apps do stuff.

But they could never build a real OS with security and memory protection out
of it. So Apple bought NeXT to get industrial strength unix as their core OS,
and switched all Apple development to NeXTStep, or at least the modern
derivative of it, called Cocoa.

My dust covered Inside Mac volumes were made useless nearly 20 years ago.

~~~
Someone
_”Over time they added cooperative multitasking”_

You may know, but for readers who don’t: _”they”_ didn’t, Andy Hertzfeld did
([https://www.folklore.org/StoryView.py?story=Switcher.txt](https://www.folklore.org/StoryView.py?story=Switcher.txt))

It helped that he had intimate knowledge of the Mac operating system’s
internals, but many of them were documented in Inside Macintosh, and others
could have been found with (quite) a bit of effort; one didn’t have to be at
Apple or even have access to the system’s source code to implement that.

And those volumes aren’t useless; they are reminders of about the last time
hacking an OS was fun :-;

~~~
yuhong
What is fun is the Switcher/Multi-Mac debacle. Notice that it was mentioned
that "I knew that releasing it would have me having to keep up with all the
new ROM releases from Apple in the future." At the time, even with the 128K
ROM I think they still had to put special code to support Switcher into there
(Andy was also working on the Font Manager at the time).

------
kweinber
This is also an important example of how limiting an anti-social attitude can
be when trying to collaborate and have a large affect on the world. As
brilliant as Jon is, he wasted an inordinate amount of time making up for
constantly insulting people, places, and approaches. (Even today he couldn't
avoid insulting all of Tulsa OK).

Imagine where windowing systems could be if his brilliant work, API thoughts,
and insights weren't delivered with insults, arrogance and vitriol.

At the end it is sad that he was proud of being right even though he was an
_hole (his word). It could have been that he was right and his best ideas were
in common use.

~~~
MycroftJones
I didn't realize people were so sensitive in the field. Compared to Linus,
Theo de Raadt, Richard Stallman, etc, Jon seemed to be cruising at a
comfortable level of Germanic straight-forward truth-telling, no real a
__holishness I could detect. Guess I should reset my etiquette and politeness
filters.

~~~
adrianratnapala
I note that the people you name all built their communities through work they
did well outside the corporate world.

~~~
digi_owl
And at least two of them have a undeserved reputation.

~~~
MycroftJones
You mean Theo and Linus? Yes.

~~~
rbanffy
Theo's reputation is very well deserved.

------
mwcampbell
I've read some of Don Hopkins' comments about all the cool things that were
done with PostScript running in the NeWS server. I wonder, if NeWS had
survived long enough that Sun had to add accessibility for people with
disabilities (to sell to governments and schools if nothing else), how would
they have done it? Today, the current state of the art is very chatty IPC
(meaning tens of microseconds per cross-process call), partially assisted by
bulk fetching and caching. To appreciate how bad that can be, think about a
screen reader making at least one IPC call per word when reading text, to ask
the application about word boundaries and bounding rectangles. That's a
problem I hope to solve someday. In a parallel universe, though, maybe the
screen reader is running inside the NeWS server, in the same address space as
a PostScript-based UI toolkit.

~~~
DonHopkins
I've written up some thoughts and discussions about accessibility and
JavaScript, and discussed them a few times here!

I discovered the great work of Morgan Dixon and James Fogarty, which proves
that you can do some amazing things with screen scraping, pattern matching,
visual deconstruction, augmentation and reconstruction! His work needs to be
combined with platform specific accessibility APIs via JavaScript.

I'm proposing "aQuery", a high level scriptable accessibility tool that is to
native user interface components like jQuery is to DOM, for selecting and
querying components, matching visual patterns, handing events, abstracting
platform dependencies and high level service interfaces, building and
scripting higher level widgets and applications, etc.

[http://donhopkins.com/mediawiki/index.php/AQuery](http://donhopkins.com/mediawiki/index.php/AQuery)

[https://news.ycombinator.com/item?id=11520967](https://news.ycombinator.com/item?id=11520967)

Morgan Dixon's and James Fogarty's work is truly breathtaking and eye opening,
and I would love for that to be a core part of a scriptable hybrid Screen
Scraping / Accessibility API approach.

Screen scraping techniques are very powerful, but have limitations.
Accessibility APIs are very powerful, but have different limitations. But
using both approaches together, screencasting and re-composing visual
elements, and tightly integrating it with JavaScript, enables a much wider and
interesting range of possibilities.

Think of it like augmented reality for virtualizing desktop user interfaces.
The beauty of Morgan's Prefab is how it works across different platforms and
web browsers, over virtual desktops, and how it can control, sample, measure,
modify, augment and recompose guis of existing unmodified applications, even
dynamic language translation, so they're much more accessible and easier to
use!

[https://news.ycombinator.com/item?id=12425668](https://news.ycombinator.com/item?id=12425668)

This link has the most up-to-date links to Morgan's work, and his demo videos!

[https://news.ycombinator.com/item?id=14182061](https://news.ycombinator.com/item?id=14182061)

[https://prefab.github.io/](https://prefab.github.io/)

Prefab: The Pixel-Based Reverse Engineering Toolkit Prefab is a system for
reverse engineering the interface structure of graphical interfaces from their
pixels. In other words, Prefab looks at the pixels of an existing interface
and returns a tree structure, like a web-page's Document Object Model, that
you can then use to modify the original interface in some way. Prefab works
from example images of widgets; it decomposes those widgets into small parts,
and exactly matches those parts in screenshots of an interface. Prefab does
this many times per second to help you modify interfaces in real time. Imagine
if you could modify any graphical interface? With Prefab, you can explore this
question!

[https://www.youtube.com/watch?v=w4S5ZtnaUKE](https://www.youtube.com/watch?v=w4S5ZtnaUKE)

Imagine if every interface was open source. Any of us could modify the
software we use every day. Unfortunately, we don't have the source.

Prefab realizes this vision using only the pixels of everyday interfaces. This
video shows how we advanced the capabilities of Prefab to understand interface
content and hierarchy. We use Prefab to add new functionality to Microsoft
Word, Skype, and Google Chrome. These demonstrations show how Prefab can be
used to translate the language of interfaces, add tutorials to interfaces, and
add or remove content from interfaces solely from their pixels. Prefab
represents a new approach to deploying HCI research in everyday software, and
is also the first step toward a future where anybody can modify any interface.

More Prefab demos:

[https://prefab.github.io/videos.html](https://prefab.github.io/videos.html)

~~~
mwcampbell
Fascinating! What are some of the limitations of screen scraping that are
addressed by accessibility APIs? Is it primarily the unreliability? Do you
envision using an accessibility API as the primary source of information, with
screen scraping as a fallback?

~~~
DonHopkins
Accessibility APIs expose lots of rich high level information like associating
a label with a widget (to name one simple example, but it gets MUCH more
complex than that). And of course the position and meaning and state of each
object on the screen.

There needs to be a higher level scriptable way to get a handle on all that
complexity, like jQuery helps automate the creation and manipulation and
abstraction of HTML DOM and events and handlers.

PhoneGap/Cordova plugins and NativeScript both take a similar approach: they
have a generic Objective C / Java / Whatever <=> JavaScript bridge that lets
you directly call all (or most) of the native APIs, including accessibility,
directly on each platform. Then you write higher level platform independent
APIs on top of the native APIs in JavaScript, a different one for each
platform, but the same high level interface to JavaScript programmers.

[https://docs.nativescript.org/core-concepts/accessing-
native...](https://docs.nativescript.org/core-concepts/accessing-native-apis-
with-javascript)

I would try to use the native API as much as possible since they're precise
yet tedious. It should have a platform-independent accessibility-specific
selector language like xpath or jQuery selectors, which should be implemented
efficiently in native code like querySelector. The pattern matching engine
would send asynchronous events back to JavaScript. You could write JavaScript
handlers for patterns of pixels as well as accessibility path patterns
appearing and disappearing, like jQuery lets you bind handlers to patterns of
DOM elements that don't exist yet, instead of concrete existing elements.
Those handlers would create higher level widgets that could manage those
existing pixels and widgets. (Like recognizing a youtube video player in any
web browser window, and wrapping it in an aQuery widget implementing an
abstract VideoPlayer interface, for example.)

Of course calling the native accessibility API is lighter weight than screen
scraping and pixel matching, and you could use the native API to drill down to
just the region of pixels you want to match or screencast, to minimize the
amount of screen scraping and pixel matching required.

------
DonHopkins
"A couple of decades ago I bough a Sun Ultra-60 and asked whether it was worth
paying for the dual processor version. The answer that I got was "Yes. You
need one processor to run X and another for everything else."

People cursed with diskless Sun 3/50's would run xterms and emacs's across the
net on each other's workstations instead of locally. It was noticeably less
sluggish, because you didn't get hit with all the heavyweight process context
switching between X clients and server every keystroke.

------
badsectoracula
> The only really worthwhile thing about X was the distributed extension
> registration mechanism. All of the input, graphics and other crap should be
> moved to extension #1. That way, it won't be mandatory in conforming
> implementations once that stuff was obsolete. As you probably know, that's
> where we are today; nobody uses that stuff but it's like the corner of an
> Intel chip that implements the original instruction set.

On the other hand, all of the input, graphics and "other crap" being mandatory
means that as a developer you can pretty much guarantee that they are there
and if you care about having your stuff work everywhere (well, everywhere X is
available anyway) you can simply rely on that without having to support a
bunch of different APIs that may or may not be there (see the audio situation
a few years ago in Linux).

(also FWIW a lot of people use the X primitives, not everyone uses Gtk or Qt)

~~~
kpxxx
I'm not quite sure I believe that a lot of people use the X primitives. The
alternative to Gtk and Qt is most often not raw Xlib. There are alternative
toolkits such as Motif, Xt. And then graphics abstractions such as SDL.
Obviously all of these (including Gtk and Qt) use at least some of the X
primitives in their rendering or themeing engines, but direct use of Xlib
primitives is quite rare. And I think the whole point of the argument is that
the commonly used primitives today are things like XRENDER, which aren't
really primitives since they are an extension. Precisely the point being made.

Basically, name me an app that uses solely X11 primitives without the use of
any extensions and no overlying library over libX11 (and no, xclock doesn't
count)

~~~
badsectoracula
Of course i include using toolkits that themselves use X primitives, not only
using Xlib directly :-).

For example my own Little Forms library [0] uses the X server's drawing and
text operations (you can use Xft instead, it is a build option, but you can
also make a static library for binaries that rely only on xlib and nothing
else).

[0] [http://runtimeterror.com/rep/lforms](http://runtimeterror.com/rep/lforms)

------
agumonkey
DonHopkins is on HN from time to time, he's always full of things to say about
this. Waiting for the wall of history :)

------
DonHopkins
John Steinhart is outstanding in his field!

Sometimes he's even out driving a tractor in his field! ;)

~~~
MycroftJones
In that thread, it mentiond that NeWS had "problems". Can you tell us what
those problems were?

~~~
DonHopkins
I don't know where to begin, or when to stop, so I'll pick something at random
and jump around.

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](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...](http://www.donhopkins.com/home/catalog/unix-
haters/x-windows/i39l.html)

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](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](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/index.html)

[http://www.donhopkins.com/home/catalog/hyperlook/Warehouse1....](http://www.donhopkins.com/home/catalog/hyperlook/Warehouse1.gif)

[http://www.donhopkins.com/home/catalog/hyperlook/ButtonIdeas...](http://www.donhopkins.com/home/catalog/hyperlook/ButtonIdeas4.gif)

[http://www.donhopkins.com/home/catalog/hyperlook/TalkInterfa...](http://www.donhopkins.com/home/catalog/hyperlook/TalkInterfacing.gif)

[http://www.donhopkins.com/home/catalog/hyperlook/TalkRunTime...](http://www.donhopkins.com/home/catalog/hyperlook/TalkRunTime.gif)

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.

~~~
eadmund
> X11 window managers must grab the server in order to animate rubber-band
> feedback over the screen when resizing and moving windows.

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?

~~~
DonHopkins
I think the benefits of extensibility far outweigh any differences from
whether the window manager supports tiling or overlapping windows. Ideally it
should be general purpose enough to support both.

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/...](http://www.chilton-
computing.org.uk/inf/literature/books/wm/overview.htm)

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/...](http://www.chilton-
computing.org.uk/inf/literature/books/wm/p003.htm)

"Ten Years of Window Systems - A Retrospective View" by Warren Teitelman:
[http://www.chilton-
computing.org.uk/inf/literature/books/wm/...](http://www.chilton-
computing.org.uk/inf/literature/books/wm/p004.htm)

"SunDew - A Distributed and Extensible Window System" by Games Gosling:
[http://www.chilton-
computing.org.uk/inf/literature/books/wm/...](http://www.chilton-
computing.org.uk/inf/literature/books/wm/p005.htm)

"User Interface Working Group Discussions": [http://www.chilton-
computing.org.uk/inf/literature/books/wm/...](http://www.chilton-
computing.org.uk/inf/literature/books/wm/p017.htm)

"User Interface Working Group Final Report": [http://www.chilton-
computing.org.uk/inf/literature/books/wm/...](http://www.chilton-
computing.org.uk/inf/literature/books/wm/p018.htm)

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.

------
adrianratnapala
Through most of that article I was thinking "Yep, that's the kind of train-
wreck you get when you design by committee, or worse by political need".

But toward the end, he says that the particular _kind_ of technical train-
wreck that they got was similar to the Mac API (presumably the this means the
pre-OS X OS). _" [As a resulting of accidentally being lots of databases] the
X API is wide and shallow like the Mac, and full of interesting race
conditions to boot."_

Anyway, I didn't think that design by committee was one of Apples weaknesses.

------
jimjimjim
still better than web apps.

------
grabcocque
I doubt it will come as a surprise to anyone that X was fundamentally ill
conceived from the very beginning. It’s one of those unfortunate side effects
of unintended consequences that Unix history saddled us with it for twenty
years longer than we’d ideally have wanted.

It fascinates me that something so widely regarded as Bad and Wrong, proved so
hard to replace when it’s baked into a system. I think there’s a cautionary
tale about the necessity of getting your core APIs right, because you might
never be able to get rid of them.

~~~
pjmlp
Having used a multitude of OSes since the 80's and having digital archeology
as one of my hobbies, I think it applies to everything in UNIX's design.

~~~
MycroftJones
I would like to hear more. The Unix core API is pretty simple and durable;
what was better than it? Other than Plan9? SmallTalk doesn't really count.

~~~
pjmlp
For starters having been written in C, after the Assembly and B rewrites, when
we already had safer systems programming languages in the early 60's.

IBM for example did most of their RISC research with an OS written in PL/8,
where they prototyped many ideas about modular compilers, a few of them
visible in how LLVM works.

Then by being a plain CLI based OS versus what was being done at Xerox PARC
with Xerox Star and Pilot (done in Mesa).

NeXTSTep was probably the only variant that got close of the Mac, Amiga and
Atari multimedia capabilities, and even it wasn't a pure UNIX, rather used it
as a means to bring applications into the NeXT world.

Many mainframe ideas about OS security are still not part of any UNIX clone,
as another example.

~~~
MycroftJones
Thank you for explaining. I disagree, but then, I started with the Commodore
64 and BASIC, and have missed them ever since. C and LISP version 1 sort of
fit in the same space. I hate any language that hides the machine from me.
Also don't really like clicky gooey stuff. Text and typing is where it is at.
Matter of taste really. But newLISP is a good mix of hardware access with
safety.

