HyperLook (which ran on NeWS, and was like a networked version of Hypercard based on PostScript) was kind of like looking outwards through windows, in the way Rob Pike described the Blit (although it was architecturally quite different).
I think his point was that window frames should be like dynamically typed polymorphic collections possibly containing multiple differently typed components that can change over time (like JavaScript arrays), not statically typed single-element containers that are permanently bound to the same component type which can't ever change (like C variables).
With X11, the client comes first, and the window manager simply slaps a generic window frame around it, subject to some pre-defined client-specified customizations like ICCCM properties to control the window dressing, but not much more, and not under the control of the user.
With HyperLook, the "stack/background/card" or window frame came first, and you (the user at runtime, not just the developer at design time) could compose any other components and applications together in your own stacks, by copying and pasting them out of other stacks or warehouses of pre-configured components.
https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g...
For example, I implemented SimCity for HyperLook as a client that ran in a separate process than the window server, and sent messages over the local network and drew into shared memory bitmaps. SimCity had its own custom frames ("screw-up windows") that looked more "mayoral" than normal windows.
https://cdn-images-1.medium.com/max/2560/0*ZM8s95LNxemc5Enz....
There were multiple map and editor views that you could copy and paste into other stacks while they were running, or you could copy widgets like buttons or drawing editors into the SimCity stack while it was running. So you could copy and paste the "RCI" gauge into your graphics editor window to keep an eye on it while you worked, or paste a clock into your SimCity window to see when it was time to stop playing and get some sleep. And you could even hit the "props" key on the clock to bring up a PostScript graphics editor that let you totally customize how it looked!
https://cdn-images-1.medium.com/max/600/0*oHtC0F5qK83ADw1H.g...
It had "warehouse" stacks containing collections of pre-configured component prototypes (including widgets, applets, and window management controls like close buttons, resize corners, navigation buttons, clocks, graphics editors, etc) that you could copy and paste into your own stacks, and which would automatically be listed in the "New Object" menu you get in edit mode, to create them in place without opening up the warehouse:
https://cdn-images-1.medium.com/max/600/0*sHClGU8ALljuRQKb.g...
https://cdn-images-1.medium.com/max/600/0*QwIQ_GLxQl1v968F.g...
https://cdn-images-1.medium.com/max/600/0*aWbuo6k_eJuZnUmV.g...
https://cdn-images-1.medium.com/max/600/0*zya4vNBP3libpNSA.g...
https://cdn-images-1.medium.com/max/600/1*G0LWky2iejYm4IGBsU...
Normal X11 window managers put the cart before the donkey. The window frames are generic, stupid and unscriptable, and can't even be customized by the user, or saved and restored later. The client comes first, with just one client per generic frame. You can't move or copy a widget or panel from one frame to another, to use them together in the same window. That's terribly limited and primitive.
We implemented a more-or-less traditional (but better than normal) ICCCM X11 window manager in PostScript for X11/NeWS, which had tabbed windows, pie menus, rooms, scrolling virtual desktop, etc, uniformly for all NeWS apps and X11 clients. But the next step (not NeXT Step) was to use HyperLook to break out of the limited one-client-per-frame paradigm.
http://www.art.net/~hopkins/Don/unix-haters/x-windows/i39l.h...
(It's interesting to note that David Rosenthal, the author of the ICCCM specification, was also one of the architects of NeWS, along with James Gosling.)
Our plan was to use HyperLook to implement a totally different kind of integrated scriptable X11 (and NeWS) window manager, so you could compose multiple X11 clients into the same frame along with HyperLook widgets and scripts. You could integrate multiple X11 clients and NeWS components into fully customizable seamless task oriented user interfaces, instead of switching between windows and copying and pasting between a bunch of separate monolithic clients that don't know about each other. But unfortunately Sun canceled NeWS before we could do that.
Here's some more stuff I've written about that stuff, and how window managers should be implemented today in JavaScript:
https://news.ycombinator.com/item?id=18837730
https://news.ycombinator.com/item?id=18865242
https://news.ycombinator.com/item?id=5861229
https://news.ycombinator.com/item?id=16839825
https://news.ycombinator.com/item?id=18314265
https://news.ycombinator.com/item?id=8546507
>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!
> I think his point was that window frames should be like dynamically typed polymorphic collections possibly containing multiple differently typed components that can change over time (like JavaScript arrays), not statically typed single-element containers that are permanently bound to the same component type which can't ever change (like C variables).
Well, dynamically typed, yes, and changing over time, but I don't think he was talking about sticking your editor and your command line in the same window at the same time. Rather, you could run a program in an mpx window on the Blit, and it would draw in that window until it was done, and then you would get your shell prompt back in that window.
I know this isn't really related to the overall question of end-user customizability and composability that you're focusing on here, but I dig the olwm-style pinned dropdown menus in your last screenshot there. It's a shame neither Open Look nor olwm nor olvwm ever did antialiased text — I know it was important for the window manager not to eat the entire palette of your cgfour or NCD, but when all your chrome text is black on slate grey, a couple of greyscale levels would have gone a long way.
Your other links are timely, since I'm trying to figure out how to do the BubbleOS windowing system Wercam this week, maybe using Unix-domain sockets and shared-memory bitmaps, or rather pixmaps; the thing that sounds most inspiring to me is Genode's nitpicker, but supporting the interposition-based design of the nitpicker window manager would require either an extra copy of all the pixels (to put them in the right place in the framed window) or a draw command that involves a whole sequence of rectangles instead of just one. I'm kind of thinking that by default windows will be embedded in my shell, like graphics in Jupyter, and then I'll see how things go from there. https://gitlab.com/kragen/bubbleos/tree/master/wercam