You made my day! I'm so delighted to hear you're pissed that people call it X-Windows. ;) Thank you for letting me know my long term project of always calling it X-Windows worked perfectly as planned. I've been systematically calling it X-Windows to piss people off since June 1988, when I read the article "Things That Happen When You Say ‘X Windows’" in my copy of Volume 1 Number 2 of the June 1988 of the “XNextEvent” newsletter, “The Official Newsletter of XUG, the X User’s Group” (which I quoted above):

https://news.ycombinator.com/item?id=22501380

From the end of the X-Windows Disaster article:

>Don wrote the chapter on the X-Windows Disaster. (To annoy X fanatics, Don specifically asked that we include the hyphen after the letter "X,", as well as the plural of the word "Windows," in his chapter title.

I started programming X10 in June 1986. Here's my first X10 program, a pie menu test application (I was calling them "theta menus" then):

https://donhopkins.com/home/archive/piemenu/theta.test/

After that I modified the X10 "uwm" window manager to support pie menus, and integrated it with FORTH so I could interactivally program and extend the window manager in FORTH, and use it to implement and perform an experiment comparing pie menus with linear menus.

https://medium.com/@donhopkins/an-empirical-comparison-of-pi...

Forth pie menu X10 window manager source code (the main FORTH part -- other C and FORTH source code is in the same directory):

https://donhopkins.com/home/archive/piemenu/uwm/fuwm-main.f

X10 Pie Menu Window Manager:

https://www.youtube.com/watch?v=IJhvB6kwmog

Then I moved on from X10 to NeWS (and from FORTH to PostScript), because NeWS was so much better than X10 or X11, and supported round windows and non-terrible graphics.

At Sun in 1991 I helped write an X-Windows ICCCM X11 window manager in PostScript so NeWS could manage X-Windows, which supported non-rectangular tabbed window frames, pie menus in round windows, multiple displays, multiple rooms, scrolling virtual desktops (with an iconic map that let you scroll your view around), and many other nice features that other X window managers couldn't do at the time. Plus it was faster and more efficient than any X window manager because it actually ran in the window server instead of running in a separate process and communicating over the network, so it was able to immediately synchronously handle events, provide feedback, draw rubber-band lines in the overlay, pop up and track menus immediately, perfectly support quick mouse-ahead gestures, move and resize windows instantly, all without context switching or network traffic or grabbing the server or freezing event distribution or lagging behind or missing any events, instead of being asynchronous and laggy and flakey and dropping events like all other outboard networked X11 window managers do by design. (This was extremely important when running on a slow diskless Sun 3/50 paging over the network.) The idea of running something as crucial and interactive as the window manager in a separate process using an asynchronous protocol is quite insane, inefficient, wasteful, and flakey, but that's how X was designed to be.

https://donhopkins.com/home/archive/NeWS/owm.ps.txt

Demo of the Pie Menu Tab Window Manager for The NeWS Toolkit 2.0:

https://www.youtube.com/watch?v=tMcmQk-q0k4

In 1992 I made a pie menu window manager called "piewm" based on "tvtwm", and I also ported SimCity to X11, using TCL/Tk, redesigning it to be a multi player networked game, and encountering and solving all kinds of problems trying to make X11 play a game, support multiple users, do fast shared memory graphical animation, mix sounds with a network audio mixer, and support different types of screens and devices (both black and white and color). Those experiences were what motivated me to write the Unix-Haters Handbook chapter on the X-Windows Disaster, and compare my experiences with NeWS and X-Windows.

http://www.art.net/~hopkins/Don/piemenus/index.html

>The "piewm" X11 window manager with pie menus. When I was a research programmer at CMU, faced with using X11, I realized that I needed pie menus to help me move my windows around, so I went shopping around for a reasonable window manager, and since there weren't any, I choose the least unreasonable one at the time, "tvtwm", and hacked it up with an updated version of the old X10 "uwm" pie menus, and called it "piewm". The source code is available here: piewm.tar.Z.

http://www.art.net/~hopkins/Don/piemenus/piewm.tar.Z

>The TCL/Tk pie menu widget. I accidentally ported the HyperLook version of SimCity to X11, making it multi player in the process, using the TCL/Tk toolkit, which was the only X11 toolkit that didn't suck. I needed some fancy looking graphical pie menus, so I made a TCL/Tk pie menu widget, whose window shape could be shrink-wrapped around iconic labels. The source code is available here: tkpie.tar.gz. I recorded an X11 SimCity demo, showing pie menus in action. SimCity for X11 won a "best product of 1992" award from Unix World!

http://www.art.net/~hopkins/Don/piemenus/tkpie.tar.gz

More stuff about X11 window management and multi player SimCityNet:

http://www.art.net/~hopkins/Don/unix-haters/x-windows/i39l.h...

http://www.art.net/~hopkins/Don/simcity/simcity-announcement...

http://www.art.net/~hopkins/Don/simcity/simcitynet.html

X11 SimCity Demo:

https://www.youtube.com/watch?v=Jvi98wVUmQA

Multi Player SimCityNet for X11 on Linux (you can see the date changing so fast it blurs at 1:25):

https://www.youtube.com/watch?v=_fVl4dGwUrA

Here's how fun it is trying to draw the SimCity map efficiently with X-Windows: if only a few pixels have changed (which is a very common case), instead of sending the entire image, it sorted the changed pixels by color, then used XDrawPoints to draw each batch of different colored pixels that changed. Changing colors is expensive, so if you changed colors for every dot it would be very slow, but X-Windows lets you draw a bunch of dots at any position in the same color efficiently, so SimCity finds the pixels that changed, and if there are few enough of them, it sorts them by color, then goes through setting each color and drawing every pixel that changed to that color with XDrawPoints. If more than max_pix (256) changed, it just sends the whole image. Yes, that was the most efficient way to do it if the server didn't support shared memory or was across the network on a different host, since the X protocol and graphics API is so awkward and inefficient. And even if you have the shared memory extension in your server, X still requires that you ALSO write code to support the case of no shared memory, since it still needs to be able to run over the network. Decades later when I updated the code to support different bit depths than an 8 bit color palette, computers and networks were astronomically faster, and the code was too tricky for its own good, and SimCity on the OLPC was usually running locally with shared memory anyway, so I punted, commented out that code, and just sent the image every time.

https://github.com/SimHacker/micropolis/blob/b0c5a3f495ebabb...

    /* 
     * Sending the whole image is 108108 bytes.
     * Sending points is 4.4 bytes per point.
     * One image is as big as 24570 points.
     * But we have to sort these dang things.
     */

    #define MAX_PIX 256
    int max_pix = MAX_PIX;

    [...]

    /* TODO: Fix this. I disabled this incremental drawing code for now since it seems to be buggy. */

    /* Sort the changed pixels by their color */

    qsort(pix, different, sizeof (struct Pix), (int (*)())CompareColor);

    /* Draw the points of each color that have changed */
    points = (XPoint *)malloc(sizeof (XPoint) * different);
    last = 0; pts = 0;
    for (i = 0; i <= different; i++) {
      if ((i == different) ||
      (pix[i].color != pix[last].color)) {
        XSetForeground(view->x->dpy, view->x->gc, pix[last].color);
        XDrawPoints(view->x->dpy, view->pixmap, view->x->gc,
            points, pts, CoordModeOrigin);
        if (i == different)
      break;
        pts = 0;
        last = i;
      }
      points[pts].x = pix[i].x;
      points[pts].y = pix[i].y;
      pts++;
    }
    free(points);

The map editor "DrawOverlay" code also has a lot of fun hairy optimizations to draw fast over the network, and it measure how long it takes in different situation and uses the most efficient technique (drawing the lines every time, or caching them in an offscreen pixmap overlay):

https://github.com/SimHacker/micropolis/blob/b0c5a3f495ebabb...

When I was timing and optimizing SimCity to make it run as fast as possible on X-Windows, I noticed that when you ran it super-duper flat-out fast, skipping screen updates to run the simulator in a tight loop, a huge amount of time was wasted simply redrawing the date field, since it changed so many times per screen refresh. So I implemented a special custom TCL/Tk widget just for displaying the date, which only lazily updates occasionally at a fixed frequency, and knows how to draw the text in an offscreen pixmap and "fake blur" the parts of the date that are changing quickly by overprinting the letters and digits in gray (you can't easily blur or blend text in X-Windows with an 8 bit color mapped display, so I did the next best thing that was possible and efficient, and it got the point across that time was moving very fast, without slowing the computer down or making it unresponsive).

https://github.com/SimHacker/micropolis/blob/b0c5a3f495ebabb...

More about NeWS in this recent discussion:

https://news.ycombinator.com/item?id=22455722