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

[Daniel Stone]

Hi Drew,

On 15 March 2018 at 16:53, Drew DeVault <sir at cmpwn.com> wrote:
>> 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.
>
> This is not something wlc/wlroots/sway/mpv is pushing for alone. This
> thread represents the opinions of several major players in the Wayland
> ecosystem: Sway, KDE, Mir, Way Cooler, waymonad, and bspwc are all
> represented here. Given this, it's difficult for me to accept that a
> consensus has been reached.

Unfortunately it's exceedingly rare to hear from all these projects
either on the list or IRC. I did know that KDE had implemented it,
because Martin mentioned it in a throwaway comment once. I had a vague
recollection that WLC/wlroots also implemented it, and no idea about
the rest (bspwc is something I had literally not heard of until
today).

That strikes me as a problem. So what can we do to bridge the gap
between these projects?

> It is my intention to earnestly express the opinion of our projects and
> work towards a common goal. We are all on the same team here, we just
> want to work together. However, if we can't agree on the issue of making
> CSD mandatory for all clients, we'd rather take that then have this
> protocol unmerged.

It's not absolutely mandatory for clients to render decorations, it's
just that anyone running mpv on a compositor which doesn't implement
an optional extension, won't get decorations on it. Personally I don't
think that makes for a good or useful client, but there we go.

Conversely, merging the protocol into wayland-protocols doesn't mean
that every compositor is newly required to implement server-side
decorations. After all, presentation-time and viewport have been
stable for years, and so far no-one else has implemented them, despite
specifically making it possible to have better media playback.

>> > 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 ... ?
>
> Yeah, it's not ideal. The impetus for this protocol is to solve this
> problem by getting software written by both camps to negotiate. It's
> clear we're not going to get either side to agree to buy into the other,
> so in the interests of the user we're trying to accomodate both.

I understand that, and the compromise is good. But my view here is
that compositors sticking server-side decorations on unwilling clients
are the ones upsetting the status quo. Your view seems to be that
there _is_ no status quo, so either approach is equally valid in the
absence of explicit negotiation.

>> 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.
>
> Qt (with KDE's help) was the first toolkit to support server side
> decorations - Sway adopted this protocol and sent a patch to GTK+ for
> it. This is a couple of years in the works. Qt has had
> QT_WAYLAND_DISABLE_WINDOWDECORATION for ages.

I don't really feel like an environment variable makes for status quo.

>> It is a concrete, unarguable, fact that the core Wayland protocol
>> implies client-side decorations. The protocol text in this thread
>> acknowledges that fact:
>
> This isn't true. The core Wayland protocol takes no stance at all on any
> kind of decorations. It's designed to accommodate for systems where CSD
> doesn't even make sense, like IVI systems or phones.

Yes, but I think this reinforces my point. If an IVI, phone or
set-top-box compositor suddenly started sticking decorations on the
surfaces it found, it wouldn't be useful. Saying 'but the clients
never asked _not_ to be decorated' wouldn't really help you get out of
it either.

> I don't want to drag this on much further, what changes do we need to
> make to get this merged?

I don't think prolonging the argument is helpful. Just a fairly clear
statement that in the absence of this extension and unless told
otherwise, clients which can decorate themselves, should decorate
themselves, would work for me. I don't want to be painted into a
corner where clients _can_ decorate themselves, but do not because the
compositor does not advertise an extension which requires it to be
able to decorate other clients. Peter and Pekka had some good comments
on a more technical level as well.

Cheers,
Daniel