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

Daniel Stone daniel at fooishbar.org
Thu Mar 15 15:43:44 UTC 2018


On 15 March 2018 at 15:21, Drew DeVault <sir at cmpwn.com> wrote:
> On 2018-03-15  3:16 PM, Daniel Stone wrote:
>> You could write a compositor which put decorations on everything
>> unless explicitly instructed not to, and claim victory in the name of
>> technical correctness. Even though it's double-decorating GTK+, EFL,
>> Weston, and pretty much everything deployed under the sun.
>
> In fact, I have done so. Before we started working on this protocol,
> Sway did exactly this. We have provided users the means of overriding
> the approach to decorations, including what ends up being double
> decorations sometimes.

OK, but that doesn't seem like the kind of user experience to aim for ... ?

'You might have no titlebars and controls, or one of them, or maybe
two completely different ones, depending on historical decisions made
by developers who weren't talking to each other at the time. Have
fun.'

>> We already have a specification, which is what every client expects:
>> that clients are responsible for the decorations (or absence thereof).
>> We now have a new protocol which allows the client and server, when
>> both agree, to have the server take responsibility for drawing (or not
>> drawing) the decorations. And that's fine, but why try to retcon
>> history as if the past several years never existed, just because you
>> disagree with it?
>
> I don't think I'm being overtly "technically strict" in my
> interpretation of the standard. This assumption hasn't really been true.
> Take Xwayland, for example, a shell where the compositor has always been
> expected to handle decorations.

Xwayland isn't a shell. Xwayland requires active co-operation from the
compositor to act just like an X11 window manager, so X11 clients can
display in the shell being used. X11 has very well-established means
of doing window management via the ICCCM and EWMH, and the
implementations I've seen try to respect those as closely as they can.

> There are also other clients in the wild which are not amenable to
> client side decorations. mpv comes to mind, there was a big debate over
> it and to date it still doesn't support CSD (it uses xdg-shell).

Yes, so mpv gets no decorations unless it asks the server for them.
Neither does weston-simple-egl. There are several compositors which
will never provide decorations for mpv, because they don't support
server-side decorations. And that's OK, because that's the established
ecosystem: clients provide decorations.

> The "requirement" has never been as strong as you're implying, and
> certainly has never been expressed in the protocols.

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.

I understand you dislike Wayland's established window-management model
and you wish it was the same as X11. I disagree, but that's fine.
What's not fine, is trying to rewrite history and insulting everyone's
intelligence. You're acting as if the consensus which has underpinned
everything since the start of the project doesn't exist, just because
a) you don't like it, and b) mpv doesn't have decorations so it
invalidates everything else.

It is a concrete, unarguable, fact that the core Wayland protocol
implies client-side decorations. The protocol text in this thread
acknowledges that fact:
    By advertizing this interface the server anounces support for
server-side window decorations.

Denying facts and being disingenuous doesn't help anyone, and it's
tiring. Tiring enough that I came into this thread with the intention
of giving this protocol a couple of suggestions and a push towards
getting it merged, because I'm tired of the totally counterproductive
division between wlc/wlroots/Sway/mpv and the rest of the Wayland
world, but I've lost all motivation to continue.


More information about the wayland-devel mailing list