[PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

[Daniel Stone]

Hi Eike,

On 18 March 2018 at 16:35, Eike Hein <hein at kde.org> wrote:
> On 03/18/2018 03:55 PM, Markus Ongyerth wrote:
>>> a) Change the definition of "decoration" to "window controls as deemed
>>> appropriate by the compositor, for example ...". This leaves what's in a
>>> server-side deco and what's in a client-side deco up to servers and
>>> clients, respectively, and allows this protocol to serve more systems.
>> While a bit of rewording here (probably to the ambigous state it's in
>> xdg-shell) wouldn't hurt, this particular sentence would make CSD very weird,
>> since the client doesn't know what the compositor deems appropriate.
>> I think we should avoid the situation where clients try to guess their env,
>> not promote it even further.
>
> I hear you, but I don't think it's a problem - hang on.
>
> Let's try to cut through all the heated contention we've had going on:
> One of the issues some people in the "SSD camp" have is that in their
> minds, "CSD" means whatever GTK+ 3 is doing with header bars, since
> that's the most prominent example around.
>
> But in a wayland-devel context, to paraphrase someone from #wayland, CSD
> actually just means "the client is expected to draw whatever decoration
> it deems fit for its uses" (which could include "nothing at all").
>
> So you have two different models of thought:
>
> a) Systems where the compositor wants to put standardized decorations on
> clients to enforce/enable particular behavior and/or workflow across all
> of them.
>
> b) Systems where the compositor takes the stance of "the client knows
> best how it wants to decorate itself".
>
> In my eyes this protocol is about negotiating between these two cases,
> and that's where my proposed wording comes from. If the server
> advertises this interface, a client can opt into "I agree I'm not going
> to decorate myself and let you do it", or the client can be left to its
> own devices.
>
> I think in both case, the protocol shouldn't make any attempts at
> specifying what either the server or the client should put into a
> decoration, which is what the text does right now. I think it's both
> unnecessary and constrains us in a way we don't actually want. This
> should be removed from the protocol text.

This is a really good and useful definition, and I couldn't agree
more. I don't think language-lawyering about exactly what constitutes
decorations is going to help. (After all, one of the big demands for
this is tiling window managers, some of which currently abuse the
maximised state ...)

> Plus, there's a chance here to go 180 degrees from the current wording
> and describe the non-server-decorated case as "client shall decorate
> itself as it sees fit" explicitly, which is obvious to some of the
> Wayland community but not all, and could help with finally putting all
> this in-fighting behind us. Without introducing any new side-effects in
> the process (I think that's a free bonus, mind you - the main motivation
> is just engineering hygiene).

Works for me. Given how apparent it was from IRC that people were
misinterpreting each other's positions, I think explaining it from the
compositor point of view would be ideal. Let's see what the others
think.

Cheers,
Daniel