🚀 go-pugleaf

In <TQV1CHCxds13@ficc.uu.net>, Peter da Silva asks:
>Is there any way other than NeWS, then, to move the UI where it belongs...
>in the display the user is working on?

There's the Blit family. (Blit, Jerq, DMD5620, 630, and their
associated software -- mpx, mux, layers)

One writes the program in two parts, a host end and a terminal end.
Instead of using PostScript for the terminal end, one uses C,
cross-compile, link and download to run.  (The downloading provides a
great incentive to keep programs small) Since the terminal runs
compiled code, it can be made to run quickly.  This is A Good Idea,
since terminals tend to be CPUs with less horsepower than the host.
(of course, since various vendors want to sell you More Powerful
Machines for your desktop, they may view this sort of efficiency as A
Bad Thing) Since the terminal end is in C, one doesn't have to learn a
new language to program the display in. (I know some people would
vociferously deny that PostScript is a language:-) And one gets to use
all the tools that exist on Unix for working with C code as a
peripheral advantage.  (One could probably use some other compiled
language if one had an appropriate cross compiler -- it's just the
only cross compiler I know of for blits is a C compiler)

The graphics library has none of the fancy classing stuff and
"advanced imaging model" of NeWS -- a simple old bitblt, line and
rectangle, character drawing and a few communication primitives. It
has non-preemptive scheduling (like NeWS), and mouse tracking is done
by the terminal.  Only monochrome, unfortunately.  No subwindows -- the
theory is that subwindows are easy to do in the application, since
they're really a UI component.  None of the gazillion graphics context
options of X11.  But then, the terminal component has access to the
raw frame buffer bits, so if it wants to do something fancy, it can
just go and do it.

Each blit application is given a bytestream, it can invent its own
protocol.  Which means a bit more work, but more flexibility.  Hello
world is not a great blit example -- it can be coded entirely in the
terminal.  A better example would be something like a text editor,
where the terminal handles display of the current screen and mouse/kbd
interaction, and the host end handles the file/unix interface.

Conceptually, it's the window system I like best, and its performance
is outstanding -- it remains the only window system I know of that
runs effectively over 9600 (or slower) baud serial lines, and runs
faster on a 68000 based 1M platform than most X11 implementations on
bigger hardware. (X11R4 is faster, I think, I've seen at least one
blit fanatic work semi-contentedly on a Sun running X11:-)

The blit doesn't bother too much about look and feel issues - it
provides a fast kernel in the terminal and lets the applications worry
about the look and feel.  (I don't particularly like the trend towards
enforcement of uniform look and feel, and the megatons of marketing
hype that surrounds things like Open Look -- I always preferred the
"make it functional, make it fast, then make it pretty" axiom)

Alas, last I heard, the nicer blits cost about as much as an X
terminal (I don't like the old Blits with long-persistence green
screens, which are cheaper), and the software doesn't come with full
src unless you get Research Unix.  Its software is also somewhat, er,
hard to port (at least judging from the cussing and swearing I heard
when someone here was trying to get mux working on his brand new
5620:-) AT&T has kept the blits a well guarded secret, it would seem.

For those who want to know more about it, the main reference is:

%A Rob Pike
%T The Blit: a multiplexed graphics terminal
%J Bell Laboratories Technical Journal
%V 63
%N 8 (part 2)
%D October 1984
%P 1607-1631

The programmer's manual qualifies as the smallest window system
programming manual around -- at 12 pages, it is well under the ~45 page
MGR manual and the ~60 page X10 manual.  I don't know of it in
published form anywhere, alas.

%A Rob Pike
%T The Blit Programmer's Manual (TTY Edition)
%J Eighth Edition Unix source, /usr/blit/doc/manual
%P 1-12

%A Rob Pike
%T Window Systems Should Be Transparent
%J USENIX Computing Systems
%V 1
%N 3
%P 279-296
%D Summer 1988.

%A Rob Pike
%T A text-oriented terminal multiplexor for Blits (abstract)
%J Proceedings of the USENIX 1984 Summer Conference
%C Salt Lake City, Utah
%D June 1984
%P 173

The next two are implementation refs.  The paper on hardware/software
trade-offs is good one -- that, and a paper by Bart Locanthi in a EUUG
conference ("Fast BitBlt using asm() and cpp", I think -- I don't have
the exact ref or my copy handy) explain why the blit is so darn fast
-- someone cared about performance. :-)

%A Rob Pike
%T Graphics in overlapping bitmap layers
%J ACM Transactions on Graphics
%V 2
%N 2
%D April 1983
%P 135-160

%A Rob Pike
%A Bart Locanthi
%A John Reiser
%T Hardware/software trade-offs for bitmap graphics on the Blit
%J Software - Practice and Experience
%V 15
%N 2
%D February 1985
%P 131-151

A slightly less serious article, included here since it had Blit in
the keywords:-)

%A A.K. Dewdney
%T Computer recreations: at Bell Labs work is play
and terminal diseases ate benign
%J Scientific American
%V 253
%N 3
%D September 1985
%P 12-16
%K Blit, DMD 5620, crabs

There are also related references for sam (a nice text editor, not my
first preference, but certainly my second. It also runs under X11) and
pi (a debugger -- also in the Oct 84 Bell Labs Tech. Journal) And
there's Rob Pike's paper on "A Concurrent Window System" in Usenix
Computing Systems, v2, no.2, pp. 133-153, Spring, 1989 describing a
multithreaded window system written in NewSqeak ("a language for
communicating with mice":-)