I generally like CSD, but I think SSD support should be a standard. But I just wonder about a side solution: wouldn't it be possible to do a CSD wrapper app for apps not rendering their own decorations? It would be a proxy Wayland compositor, that would push out windows with decorations. It could even support XDG-Decoration. Of course it is not a perfect solution, because then packager or desktop environment would have to decide if to wrap the command invocation with this proxy compositor. It probably could be done with two .desktop files one with the wrapper and OnlyShowIn=GNOME and the other without it with NotShowIn=GNOME.

It sucks that GNOME's world view on the issue is a push back for other projects.

Windows is CSD AFAIK, but when the app is not responding it will draw decorations for it. That's one of the many benefits of supporting it.

Windows is sort of a hybrid. The close/minimize/maximize buttons, border, and background blur are rendered by the server (the background blur on Vista and windows 7 couldn't possibly be rendered by the client), but I think the window caption is rendered by the application.

I remember seeing the caption with appended "(Not Responding)" and cursory Google Image search shows me windows like that.

i.e. https://answers.microsoft.com/en-us/windows/forum/windows_7-...

This is complete tragedy for user like me, who can't stand window decorations and see no use for it. This lack of coherent look and feel seems as very backwards step to visual smog. Thanks but no thanks.

The lack of server side window decorations has much more severe implications beyond aesthetics. Unresponsive applications can not be closed by clicking the X button. And for the compositor to find out if an application is unresponsive or not literally means solving the halting problem.

> Unresponsive applications can not be closed by clicking the X button.

They cannot be closed with server decorations either; if the client doesn't process the even queue and ignores WM_DELETE_WINDOW, it doesn't matter who paints the decoration.

> for the compositor to find out if an application is unresponsive or not literally means solving the halting problem.

Not in Wayland; if the client doesn't process events, the compositor knows that. It is just a matter of deciding on timeout value and then letting the user know (mutter does that, for example).

---

However, client side decorations ho have much more severe implications beyond estetic. For starters, with server decorations, you cannot guarantee frame-perfect synchronization of decoration and client area painting; with client decorations, you can, the same process does it.

Does Wayland not have an equivalent of _NET_WM_PID?

Strictly speaking, Wayland doesn't need it. The connection is always unix socket, so it is easy to find out the pid on the other end, reliably, without relying on well behaved client setting up things correctly.

macOS uses client-side decorations in its windowing system, and doesn’t have this issue with inconsistency. Maybe the problem is not in the design of the compositor?

Cocoa (and most Wayland compositors) have default decoration. Gnome does not. That's left to app makers to do it. The issue is not the design of the compositor, just the lack of a default decoration.