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

[Eike Hein]

How about:

<entry name="client_side" value="1" summary="no server-side decoration"/>
<entry name="server_side" value="2" summary="server-side decoration"/>

And as description:

"This interface allows a server to announce support for server-side
decorations and optionally express a preference for using them.

A client can use this protocol to request being decorated by a
supporting server.

If server and client do not negotiate the use of a server-side
decoration using this protocol, clients continue to self-decorate as
they see fit."

Cheers,
Eike


On 03/19/2018 04:34 AM, Drew DeVault wrote:
> To summarize the state of affairs here, the purpose of this protocol is
> to communicate:
> 
> - The compositor's preference to use SSD or leave the client to its own
>   devices
> - The choice of the client to have SSD displayed
> 
> We can completely remove CSD from the question because the term is
> barely meaningful. CSD is just a code-word for "some client-provided
> mechanism for window manipulation". SSD on the other hand is an apt
> description for what the server is going to do here.
> 
> I think we can settle the matter by making the following change to
> Simon's proposal:
> 
>     <enum name="mode">
>       <description summary="window decoration modes">
>         These values describe window decoration modes.
>       </description>
> -     <entry name="client_side" value="1" summary="client-side window decoration"/>
> -     <entry name="server_side" value="2" summary="server-side window decoration"/>
> +     <entry name="server_side" value="1" summary="server-side window decoration"/>
> +     <entry name="none" value="2" summary="no window decoration"/>
>     </enum>
> 
> Then updating the prose accordingly. We can include a note along the
> lines of "if the client chooses not to use server-side decorations, it
> is responsible for its own window management operations."
> 
> --
> Drew DeVault
>