News for hackers. Stuff that matters.
Re:Wayland: “Move fast and break things” as a moral imperative by sprash on Sunday May 23, 2021 @06:53AM (#27254066)
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.
Re:Wayland: “Move fast and break things” as a moral imperative by vetinari on Sunday May 23, 2021 @07:17AM (#27254174)
> 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.

Re:Wayland: “Move fast and break things” as a moral imperative by hawski on Sunday May 23, 2021 @08:37AM (#27254588)
Does Wayland not have an equivalent of _NET_WM_PID?
Re:Wayland: “Move fast and break things” as a moral imperative by vetinari on Monday May 24, 2021 @07:08AM (#27263022)
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.