[KerrAvon]

The window manager is part of the UI stack on macOS and can’t be replaced in the way a Linux user would expect.

There are utilities that attempt to provide some alternative window behaviors; they are all hacks — by necessity — because macOS does not support altering window behavior/appearance globally.

[corrral]

> they are all hacks — by necessity

To be clear, though, the "hack" I use (Spectacle) isn't even actively developed anymore, but has worked flawlessly through a decade of macOS upgrades. Zero problems, zero glitches, even with multiple monitors it just works exactly how I expect.

If only non-"hack" Linux GUI software were this stable and perfectly-functioning over such a long time span.

[DonHopkins]

And X-Windows + ICCCM (I39L) isn't a hack??!

And why doesn't X-Windows also support altering menu appearance globally (like supporting pie menus in every app), too? NeWS did, over three decades ago.

NeWS Tab Window Demo (1990)

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

X-Windows Disaster

https://donhopkins.medium.com/the-x-windows-disaster-128d398...

Ice Cube: The Lethal Weapon

One of the fundamental design goals of X was to separate the window manager from the window server. “Mechanism, not policy” was the mantra. That is, the X server provided a mechanism for drawing on the screen and managing windows, but did not implement a particular policy for human-computer interaction. While this might have seemed like a good idea at the time (especially if you are in a research community, experimenting with different approaches for solving the human-computer interaction problem), it can create a veritable user interface Tower of Babel.

If you sit down at a friend’s Macintosh, with its single mouse button, you can use it with no problems. If you sit down at a friend’s Windows box, with two buttons, you can use it, again with no problems. But just try making sense of a friend’s X terminal: three buttons, each one programmed a different way to perform a different function on each different day of the week — and that’s before you consider combinations like control-left-button, shift-right-button, control-shift-meta-middle-button, and so on. Things are not much better from the programmer’s point of view.

As a result, one of the most amazing pieces of literature to come out of the X Consortium is the “Inter Client Communication Conventions Manual,” more fondly known as the “ICCCM”, “Ice Cubed,” or “I39L” (short for “I, 39 letters, L”). It describes protocols that X clients must use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late — by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.

The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn’t work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It’s so difficult, that many of the benefits just aren’t worth the hassle of compliance. And when one program doesn’t comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release.

In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry’s standard naked emperor.

Using these toolkits is like trying to make a bookshelf out of mashed potatoes. - Jamie Zawinski

[bitwize]

The good news is that just as X has a modern replacement in Wayland, there's a modern replacement for NeWS -- the browser/Electron. The architecture is fundamentally similar: the server uploads code to present the UI to the client. It's just in JavaScript instead of PostScript. It would take a bit of work, but something like a desktop environment that runs as a single full-screen Electron app with a React UI should be feasible.

[DonHopkins]

I wrote the following description of how NeWS relates to modern web browsers and "AJAX" in the NeWS article on Wikipedia, and I also worked on TNT (The NeWS Toolkit) at Sun:

https://en.wikipedia.org/wiki/NeWS

>NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:

>- used PostScript code instead of JavaScript for programming.

>- used PostScript graphics instead of DHTML and CSS for rendering.

>- used PostScript data instead of XML and JSON for data representation.

>TNT-based applications

>The best example of such a library is TNT (The NeWS Toolkit) which Sun released in 1989. Sun also shipped an earlier "Lite" toolkit intended for example purposes and making small programs.

Here's a good example of a TNT application I developed called "PizzaTool" that shipped with Solaris 2 / SVR4 Unix OpenWindows:

https://medium.com/@donhopkins/the-story-of-sun-microsystems...

>The Story of Sun Microsystems PizzaTool: How I accidentally ordered my first pizza over the internet.

It was meant to be a programming example for TNT, so the object oriented PostScript source code is heavily commented:

https://www.donhopkins.com/home/archive/NeWS/pizzatool.txt

And it has a manual page:

https://donhopkins.com/home/archive/NeWS/pizzatool.6

Before going to Sun, I also developed an early hypermedia browser and authoring tool called HyperTIES written in NeWS and using UniPress Emacs at the University of Maryland Human Computer Interaction Lab, which supported pie menus and tabbed windows. That is illustrated on both the NeWS and Tab (interface) pages on Wikipedia:

https://en.wikipedia.org/wiki/NeWS

https://en.wikipedia.org/wiki/Tab_(interface)

https://en.wikipedia.org/wiki/NeWS#/media/File:HyperTIESAuth...

>HyperTIES is an early hypermedia browser developed under the direction of Dr. Ben Shneiderman at the University of Maryland Human Computer Interaction Lab. This screen snapshot shows the HyperTIES authoring tool (built with UniPress's Gosling Emacs text editor, written in MockLisp) and browser (built with the NeWS window system, written in PostScript, C and Forth). The tabbed windows and pie menu reusable components were developed by Don Hopkins, who also developed the NeWS Emacs (NeMACS) and HyperTIES user interfaces. (Sorry about the quality -- this is a scan of an old screen dump printed by a laser printer.)

https://donhopkins.medium.com/designing-to-facilitate-browsi...

>Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser By Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland. Published in Hypermedia, vol. 3, 2 (1991)101–117.

https://donhopkins.medium.com/hyperties-discussions-from-hac...

>HyperTIES Discussions from Hacker News: I’m putting this lightly edited archive of a bunch of different discussions and email about HyperTIES, all together in one place here on Medium. Please forgive the rough wall of text and redundancy, but I haven’t yet had time to distill it all down into one sentence. I will just include the email I sent to Ben Shneiderman summarizing the interesting posts and links, for now. Here goes: [...]

And speaking of "good news", there was an even more wonderful user interface toolkit and deeply user customizable window manager for NeWS, like HyperCard with PostScript programming and colorful stencil/paint graphics and networking instead of Hypertalk scripting and black and white bitmap graphics and no networking, which I worked on porting to TNT at the Turing Institute with Arthur van Hoff, first called "GoodNeWS", then "HyperNeWS", then finally "HyperLook", which I used to port SimCity to Unix.

You could use HyperLook's built-in PostScript drawing editor to define the shape and look and feel of any of your windows, drawing arbitrarily shaped scalable window frames and content, and cutting and pasting in scriptable buttons and widgets with graphics, like customizable clocks and custom menus, etc. The Encapsulated PostScript drawing editor itself was a reusable component that other components could incorporate, like the way the customizable clock's property sheet had drawing editors to edit the clock face and hands, so you could edit the clock's appearance.

Decades later there are still no X-Windows window managers (or even Wayland window managers) that are anything like HyperLook.

https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g...

>SimCity, Cellular Automata, and Happy Tool for HyperLook (nee HyperNeWS (nee GoodNeWS))

>HyperLook was like HyperCard for NeWS, with PostScript graphics and scripting plus networking. Here are three unique and wacky examples that plug together to show what HyperNeWS was all about, and where we could go in the future!

https://en.wikipedia.org/wiki/Arthur_van_Hoff

https://en.wikipedia.org/wiki/Turing_Institute

The "perfect" X-Windows or Wayland window manger should be more like HyperLook was 30 years ago, and enable users to easily customize the shape and graphics and behavior of their window frames and contents with a fully featured built-in graphics editor, paste in custom buttons and widgets from a library into those window frames and client applications, or create and script your own, like pie menus and arbitrarily shaped tabs stuck onto any window edge -- not just the top edge, and even edit the properties and graphics of those widgets and tabs and menus, like how the clock face and hands looked.

How would you even begin to implement something like that with X-Windows or Wayland? (It would be a waste of time to do that for X-Windows at this point, but there's a reason nobody's bothered to try in 30 years.)