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

[Drew DeVault]

> 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.

I apologise for insulting your intelligence, it was not my goal. This is
a difficult subject to have productive discourse on, because it's been a
subject of debate for a very long time and we hold very different
opinions. Our goal is to find a compromise, and this protocol is an
attempt to do that.

> 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.

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.

> > 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.

> 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.

> 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.

All of the shells (including xdg-shell) require active co-operation from
the compositor to display correcty.

> 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.

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

--
Drew DeVault