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

Sun Mar 18 06:55:16 UTC 2018

On 2018/3月/18 10:50, Eike Hein wrote:
> 
> 
> 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.
This is an optional protocol that builds upon xdg-shell.
Which, as you said, should not be present on most of these devices.

If a client never wants any decoration, it can just not implement this.
Which should be enough for all Smart-TV apps and the like.

The only problematic case would be applications intended for a normal desktop 
workflow that ask for decor if possible, but never want to draw their own.

> 
> 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.
While a bit of rewording here (probably to the ambigous state it's in 
xdg-shell) wouldn't hurt, this particular sentence would make CSD very weird, 
since the client doesn't know what the compositor deems appropriate.
I think we should avoid the situation where clients try to guess their env, 
not promote it even further.

> 
> 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.
Simplifying to that degree would be a bit much.

E.g. a simple GTK+ application would by default want to draw it's own deco.
But if the server sends a prefered SSD, it will just agree to that (think 
gparted).
Applications that have integrated other controls than those provided as 
requests over xdg-shell (gedit/evince etc.) will prefer to draw their own 
decorations, to still have the same controls.
We should get feedback on which part the applications picks, so the compositor 
can decide on whether it needs server side decor.
We can just echo what the client picked after it got our preference to the 
client most of the time.

We have other situations, where the CSD are a bit more annoying. The tabbed 
layout in xmonad/i3 (or these days sway) is a good example. It provdes a 
single bar with multiple titles, in this case we would like to tell a client 
to *really* not draw their own, we don't really have a choice to not draw 
titles.
This is a workflow that existed for quite some while, and became quite dear 
(at least to us).
This could allow applications to at least drop the title string, and in turn 
maybe make their other controls smaller, even if they insist on their own 
decor for design reasons.
> 
> Remember: This isn't about "CSD vs. SSD - which is better?!", it's about
> making this one protocol hygienic and good.
> 
> 
> Cheers,
> Eike
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180318/f685e505/attachment.sig>