Besides OpenWF support in Wayland being talked about and on the roadmap, another item that's been hotly discussed the past couple of days is about client side decoration support for the Wayland Display Server...
How about allowing the compositor to request the application not to render decorations. Then the author of the compositor can decide, if he/she wants to allow the application to control its window or not.
Kristian's point w/ unresponsive apps still relied on the app cooperating before the hang, having told where the borders and close button are. But if the compositor has no way to kill a client without cooperation, the clients can just not tell where their close button is and become invincible...
I am at a loss. How can the people making the decisions be so dismissive about the serious fundamental problems of CSD?
It all boils down to the fact that CSD is essentially nothing but a huge usability and security risk introduced for minimal gains.
Unless WM and decoration policy is within the server, misbehaving applications, not to mention outright malicious ones, can do quite much whatever they please and the user may have very limited and crude tools to try and contain them.
Someone mentioned that the problems would go away if the application defined areas within the window which the server monitors, expecting certain actions to take place and forcibly performing the associated actions, such as closing the application, if necessary. This requires both cooperation and defining these areas correctly. This means there is no guarantee of good behavior. With such a design, even with a reasonably well-behaved application, it will be difficult to properly handle situations like the "Do you want to save your changes?" dialog after clicking the close button. If the user spends any considerable time reading the dialog, they will be presented with a "Force close" dialog, which they might accidentally respond to in the affirmative, losing their work.
If CSD is insisted upon, at least the following extension to the abovementioned policy is a must to avoid the worst of problems, albeit not all: the server and the client negotiate locations, sizes and shapes for various window controls, such as the close button. The client is free to draw those areas in any way it sees fit, just like any other area. Any client that fails to negotiate reasonable values for these will be rejected or default window movement policies, locations, shapes and sizes will be applied and the corresponding buttons are forcibly drawn (preferably in the ugliest and most disturbing way possible). The handling of clicks within the areas negotiated is done by the server, with optional pre-action and post-action callbacks supplied by the client.
Client-side decorations will create lots of mess. It should be leaved allone to window managers. And anyway toolkits can experiment with some decoration-less windows, and paint decorations by itself. But client-side decorations will create lots of incoherence, security problems, freezing issues, and other possible problems.
Maybe I'm getting old but already now I hate it if clients come with their own or no decorations. It's only done for the sake of being 'different' or to dictate/limit usage patterns and we have yet to see a real useful application for it.
And as a user I don't care if CSD makes for prettier code in the compositor.