Hi Drew, On 15 March 2018 at 16:53, Drew DeVault <s...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel