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

[Eike Hein]

On 03/16/2018 12:43 AM, Daniel Stone wrote:> No, it really has. GTK+ has
always - well, until you got the patches
> for this protocol merged a month or two ago - decorated its own
> windows under Wayland. Same with Qt. Same with EFL. These are toolkits
> which have been around and deployed for several years, doing exactly
> what I'm describing. Sticking server-side decorations on them gives
> you two completely different titlebars, and anyone trying to use it
> justifiably thinking the result is an incoherent mess.

There's also millions of Wayland-based products in the market in which
Wayland clients do not render decorations, e.g. in TVs and IVI systems.
Grated, not many of them use much or any of the xdg-* protocols.

Still, compositors do not reject clients which don't render decorations.
The core protocol as-yet doesn't make an attempt to define what a
decoration is, or needs to have in it, on the basis of which it could do
so, either. If it did, the above Wayland systems would suddenly be in
violation. I think we agree these Wayland systems are actually fine and
nice to have.

I'm personally fine with assuming that many or even all of the initial
Wayland contributors assumed CSDs on desktop systems. But I think this
debate over the historic record is obscuring the real needs of this
review, which should be about making sure the protocol under review is
durable, flexible and future-proof, and doesn't introduce unintended
side-effects.

So here's the problem I see: This protocol introduces a definition of
what a decoration is and can do (move, resize, change state). A server
advertising is commits to supporting both, but when a client asks for
SSDs, the server can respond with "use CSDs"

So we have two aspects to this:

a) People are concerned a protocol like this could open the floodgates
to clients which don't implement CSDs at all and indiscriminately ask
servers for SSDs whenever they can.

b) Yet this protocol also allows servers to force clients which prefer
SSDs to force them into CSD mode, and in fact holds them to implementing
CSDs with a number of features (which don't make sense in every system).

In my eyes (b) is pretty clearly more prohibitively costly.

Servers which want to indiscriminately force all clients to provide CSDs
can just not advertize this interface, which is essentially about
letting clients know they have a preferred deco to show.

If they do advertise it, they should allow the client to express a
preference, not abuse the spirit of the protocol - essentially to
properly enable compositors which aim to establish a particular workflow
via decorations (as many existing Wayland compositors do!) - to override
it. Clients which stubbornly refuse to implement CSDs (e.g. mpv) are
unlikely to keep up their end of the bargain anyway, but I think it's
dangerous to run with such a vague definition of "decoration" with
far-reaching implications.

S. Ser said "the CSD mode allows the client to do not draw decorations
at all" in the discussion of v1, but the protocol text certainly doesn't
agree here by defining what a deco is and requiring clients to support
one. I agree with M. Blumenkrantz that the 'mode' thing seems wrong as
it is now. I think the way to go would be:

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.

b) Make the protocol about negotiating between "please deco me as you
see fit" and "I prefer to keep doing my own thing" (which can then still
be "nothing") cases. I don't think any more is needed. I think client
devs are smart enough to understand making this requests implies they
should stop drawing their own title bars, and in the latter case they're
smart enough to know how exactly they want to decorate their window, as
e.g. the GTK+ designers clearly are, and this protocol shouldn't
interfere with them. Certainly the protocol hasn't before felt the need
to teach anybody how to do decorations.

Remember: This isn't about "CSD vs. SSD - which is better?!", it's about
making this one protocol hygienic and good.


Cheers,
Eike