Thank you for checking it out! It was fun to write and run. But we couldn't talk Sun into letting us ship it for some reason! ;) Here's some more context and opinions about ICCCM (I39L), TkWM, OWM, xinit, and piewm:

https://www.donhopkins.com/home/catalog/unix-haters/x-windows/i39l.html

Here's a much better example of NeWS object oriented PostScript user interface code, written as a developer demo with lots of comments, and even a manual entry (which shipped with SVR4):

https://donhopkins.medium.com/the-story-of-sun-microsystems-pizzatool-2a7992b4c797

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

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

I just read over the OWM NeWS X11 window manager for the first time in decades, and rediscovered a little easter egg I'd completely forgotten about:

It looks for your X11 XCalc window, and wraps two levels of its sub-windows in ClassXClientCanvas, then puts the window containing the buttons into the list of Framebuffers, so then the window manager wraps all your calculator's buttons in window frames, then you can resize them and move them around and iconify them!

I'll add some comments:

    /FrameBuffers [ % Make a list of framebuffers to manage their X11 sub-windows.

        % Include all the top level root canvases (screens) 
        # except the "global root" (which contains all the screens).
        rootcanvases {
            dup /Parent get globalroot ne { pop } if
        } forall

        % Loop over all the child windows of the current framebuffer
        framebuffer /TopChild get {
          dup null eq { pop exit } if % Stop loop when done.
          dup null eq { pop } { % Not sure why it's testing the same thing again but there you go.
            dup /WM_NAME 0 s xgetproperty { % is it an X window?
              pop pop pop % It is! Discard the stuff we don't need.
              (Calculator) anchorsearch { % Is it a calculator window?
                pop pop % It is! Discard the stuff we don't need.
                /new ClassXClientCanvas send % Wrap it so we can play with it from NeWS.
                /TopChild get % Get its first child (the inner calculator window that has all the buttons).
                /new ClassXClientCanvas send % Wrap it too so we can play with it from NeWS.
                dup /Framebuffer 1 index soften put % Poke it so it looks like its parent is a framebuffer.
                % Thanks to the "dup" we will leave the calculator sub-window containing all the buttons
                % in the list of framebuffers, so the window manager knows about it,
                % and wraps all its children (the buttons) in window frames! 
                % So you get a NeWS window frame wrapping an X Calculator window wrapping an X calculator 
                % sub-window wrapping NeWS window frames wrapping X window buttons!
                exit % My work here is done! MOO HAA HAA!!!
              } { pop } ifelse
            } if
          } ifelse
          /CanvasBelow get % Check next window.
        } loop
    ] def

The practical reason I did that was because XCalc would get totally fucked up when you resized it again and again and again and again and again and again, especially small sizes, because the Athena Widget layout manager was a piece of shit, and it repeatedly scaled the initial grid layout in floating point, then rounded the window positions and sizes to integers, so they would drift a little bit each time, especially when small.

https://www.donhopkins.com/home/catalog/unix-haters/x-windows/XCalc.gif

That amused us X-Windows hating PostScript programmers on the NeWS team so much that we would laugh and laugh and roll on the floor while repeatedly resizing XCalc again and again until it looked like it got beat up in a street fight. Then we would feel sorry for XCalc, and wanted a way to repair it.

So the obvious solution was to put window frames around all the buttons, so you could resize them and lay them out nicely however you wanted. And if there was a digit or math operation you never needed, you could close it into an icon, and you could even zoom your favorite digits or math operations to "full screen" (the size of the calculator window)!

There is nothing about ICCCM that says you have to run the window manager on a root window. It's actually possible to do that with any ICCCM window manager, you just hack it so you can pass it a window id to manage instead of the root window as a command line argument, figure out the window id of the calculator with some X utility whose name I forgot (xwininfo?), and then it will do its thing on the calculator buttons. I had previously hacked OLWM do to that with a few lines of code, but of course we wanted our user friendly NeWS based X11 window manager to automatically support wrapping NeWS window frames (including tabbed window frames and pie menus) around XCalc buttons.

I'm not the most knowledgeable, but a protocol talks to another process through a specific format.

I personally think its more powerful than writing a new process to replace and existing.

My favorite example is an X11 windows manager implementing in about 18 lines of python.

Obviously there's dependencies to talk to the X server, but the power of a protocol comes from any program written in any la gage communicate with existing code.

A protocol is like the line at Subway where an api is a bar & restaurant.

They're both poorly defined, but what I think GP meant is they want something that you use something like a socket instead of FFI to interface with. You need an extra data description layer for a 'protocol' in this context because you can't rely on something like the C data model and calling convention as a given.

A protocol defines a set of primitives and their interactions, along with prescriptions where necessary, but is otherwise pretty loose generally. Especially in a Postels law world. APIs tend to be highly prescriptive with a highly specific interface and a lot of black box.

Think of the difference between an IETF RFC on say SMTP vs an email API - the RFC describes how clients and servers for mail routing interact through an almost dialog, while a typical email API has highly structured interfaces. Another wat to cut it is an API can be tested as it has inputs and return values dependent on those, while a protocol you can generally only assert compliance with the specification of the protocol.

People often assert protocols have something to so with RPC of some sort but that’s not true. Many language support protocols, which can be very similar to interfaces, but don’t have anything to do with OOP, etc. In language protocols it’s slightly different than network/IPC protocols but the intent is similar.

A couple ways to look at it:

- Protocols are descriptive, APIs are prescriptive

- Protocols are implemented, APIs implement

Great news! I'd seen river before (already had it bookmarked) but was unaware (or forgot) that it planned a feature like this. As long as they don't make it to tiling specific, which doesn't look likely given the wording of the Features section, it should be almost exactly what I want. Thanks!

for x11, there was one written in scheme and used a proper constraint-solver for layout etc.