It's a shame that all of the X replacements on the horizon also ditch the network transparency part, even though that's been a killer feature for me. I hate how much of a hack Remote Desktop is on Windows machines.
I've used ssh -X many times in my life, but at the same time, I understand why network transparency doesn't make as much sense anymore.
Classically, the X protocol kept a huge amount of state on the server, and clients would just send small requests to manipulate that data. Drawing would take place server-side, and it was relatively simple drawing at that, since UI needs were fairly modest. Text rendering occurred on the server with small strings sent from the client. And overall, it made sense to send a small amount of data to produce a large amount of graphics.
These days, however, rendering occurs almost exclusively on a combination of the client and the GPU. Everything takes place via large memory buffers, and compositing. And pushing those over the wire doesn't work nearly as well; if you're going to do that, you need protocols designed for it, with compression and delta-encoding, much like modern video codecs (but optimized for remote-desktop).
So I think it makes sense that network transparency is being rethought, in favor of protocols that look a lot more like remote-video (and remote-audio).
"Mechanism not policy" my ass. X window borders are an archetypal example of the hollowness of that oft-repeated slogan. The slogan should have been "We must strengthen our borders to protect our precious bodily fluids!" ;)
X windows all have a bunch of properties and messages and parameters relating to how to draw window borders in the server.
They have a border width, and a pixel value. They can even have a border pixmap that is tiled with the same origin as the background tile origin (hope that works for you!).
The rationale was that the server could instantly draw window borders and backgrounds before the client refreshed, to give you a bunch of stippled rectangles to look at while you waited for the client to send some drawing commands.
While NeWS's solution was simply for the server to call a PostScript procedure to instantly draw whatever kind of elaborate border plus anything else it wants the user to see (and interact with), without waiting for the client.
Nobody, but NOBODY uses window borders any more. Only the earliest ugliest toolkits like Athena (Anathema) widgets did. It was a terrible idea to build borders into the window system at that level (POLICY!!!), because nobody ever wants to draw borders in a special but extremely limited way built into the window system at a low level, and then draw the rest of the user interface some other way.
X window borders were totally useless for drawing the brutal beveled edges that were fashionable at the time, or even rounded rectangles. Supporting that would be policy! But go to town and express yourself with tiled pixmap borders, that's pure mechanism baby!
https://tronche.com/gui/x/xlib/window/attributes/border.html
https://tronche.com/gui/x/xlib/window/XSetWindowBorder.html
https://tronche.com/gui/x/xlib/window/XSetWindowBorderPixmap...
Then along came the SHAPE extension.
You'd think it would be straightforward to make an extension that lets you simply set the shape of a window by defining a region somehow.
But no, thanks to borders, each window's shape is defined by TWO regions: the smaller inner client clipping region and the larger outer border bounding region. Well actually it's more than two -- a lot more: There's also their rectangular default core protocol size (both with and without borders), which can be totally different than either of those two other regions's sizes, and modify the effective region.
In summary there are bounding, clip, default bounding, default clip, client bounding, client clip, effective bounding, and effective clip regions. Got it?
Of course all of those regions will almost always be the same since nobody actually uses borders, but thanks to the borders on every window that nobody uses, the SHAPE extension is an order of magnitude more complicated than it needs to be, and even includes a handy glossary and travel guide to all of its various regions.
https://en.wikipedia.org/wiki/Shape_extension
The extension allows defining the shape of two separate regions: the clipping and the bounding regions. These two areas are defined even for windows not using the shape extension: the clipping region is the area that can be used for drawing, the bounding region is the total area covered by the window (that is, the clipping region plus the border). The shape extension allows defining two independent shapes for these two regions.
Both the clipping and bounding are associated, in the shape extension, two areas: a default rectangular region and a possibly non-rectangular client region, defined and changed by the client as specified above. The effective region, which is the actual shape of the window, is the intersection of these two areas. This intersection is performed every time either region is changed: for example, if the client regions contains parts that are outside the default region but the default region is then enlarged, the effective region will include these parts.
https://www.x.org/releases/current/doc/libXext/shapelib.html
Status XShapeQueryExtents(Display display, Window window, Bool bounding_shaped, int x_bounding, int y_bounding, unsigned int w_bounding, unsigned int h_bounding, Bool clip_shaped, int x_clip, int y_clip, unsigned int w_clip, unsigned int *h_clip);
The border of a window is defined to be the difference between the effective bounding region and the effective clip region. If this region is empty, no border is displayed. If this region is nonempty, the border is filled using the border-tile or border-pixel of the window as specified in the core protocol. Note that a window with a nonzero border width will never be able to draw beyond the default clip region of the window. Also note that a zero border width does not prevent a window from having a border, since the clip shape can still be made smaller than the bounding shape.
Glossary
bounding region: The area of the parent window that this window will occupy. This area is divided into two parts: the border and the interior.
clip region: The interior of the window, as a subset of the bounding region. This region describes the area that will be painted with the window background when the window is cleared, will contain all graphics output to the window, and will clip any subwindows.
default bounding region: The rectangular area, as described by the core protocol window size, that covers the interior of the window and its border.
default clip region: The rectangular area, as described by the core protocol window size, that covers the interior of the window and excludes the border.
client bounding region: The region associated with a window that is directly modified via this extension when specified by ShapeBounding This region is used in conjunction with the default bounding region to produce the effective bounding region.
client clip region: The region associated with a window that is directly modified via this extension when specified by ShapeClip This region is used in conjunction with the default clip region and the client bounding region to produce the effective clip region.
effective bounding region: The actual shape of the window on the screen, including border and interior (but excluding the effects of overlapping windows). When a window has a client bounding region, the effective bounding region is the intersection of the default bounding region and the client bounding region. Otherwise, the effective bounding region is the same as the default bounding region.
effective clip region: The actual shape of the interior of the window on the screen (excluding the effects of overlapping windows). When a window has a client clip region or a client bounding region, the effective clip region is the intersection of the default clip region, the client clip region (if any) and the client bounding region (if any). Otherwise, the effective clip region is the same as the default clip region.