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

[Quentin Glidic]

(I wonder if Pekka or Daniel would like to be dropped off the CC list as 
it may be too desktop-ish for them?)

On 3/3/18 10:58 AM, Simon Ser wrote:
> Hi,
> 
> Thanks for taking time reviewing the protocol and suggesting an alternative design.
> 
> On March 2, 2018 4:36 PM, Mike Blumenkrantz <michael.blumenkrantz at gmail.com> wrote:
>> Hi,
>>
>> I agree with your point regarding a SSD-capable compositor not always wanting them, and certainly I can see the usefulness for cases such as what you've cited. However, in the example you provided, it's easy enough for an application to determine what desktop it's running in and then determine whether to use SSD--if the compositor implements and advertises this protocol then it's ultimately a client decision whether to use it.
> 
> I don't think "detecting the desktop environment" is a good idea. Some other DEs (elementary, Unity) might also prefer GTK+ CSDs even if they're not GNOME, and - supposing there's a good way to know which DE is currently running ­- hardcoding the names of DEs is a slippery slope.

Just a side note here: it is a slope clients slipped on already if they 
want to integrate with some DE settings. But I agree that it should be 
as limited as possible (and hopefully in some helper library/toolkit).


>> My issue is in the inconsistency of the protocol that has been proposed here. This is a protocol for enabling SSD; there should be no need for anything related to CSD, and I don't think there is a need for clients to have any form of protocol request to toggle between CSD and SSD.
> 
> This is not a protocol to enable SSDs, this is a protocol to negotiate client- or server-side decorations. This is stated in the protocol description.
> 
>> Based on your assertion that borderless mode would be achieved in this protocol in the CSD mode, I would raise the counterpoint that in this case the client should just destroy the zxdg\_toplevel\_decoration_v1 object which, according to the destroy request, would revert to the surface using CSD anyway, furthering my assessment that there is indeed no need for any mention of CSD in the protocol requests.
> 
> This is racy - there will be frames with both client-side and server-side decorations.

(Will answer and elaborate on v2.)

>> This change allows for everything except the destroy request to be removed from zxdg\_toplevel\_decoration_v1, greatly simplifying the protocol as well as implementations of it. The case of the compositor "ignoring" the request to create SSD also becomes moot as well, since all that would mean is the compositor has chosen to use a borderless state at this time (e.g., tiling layout) which is irrelevant to the client anyway.
> 
> I don't understand your last point. A tiling layout would be exposed as SSD to the client.

Or not, tiling is orthogonal to CSD/SSD. We will have a tiling state in 
xdg-shell at some point, hopefully, that will enable nicer visuals for 
CSD too.


>> This aside, there's some other items of note here, such as the lack of precision related to when the change in decoration management state takes effect: most likely it should be applied on the next surface commit? I think this should be specified in the zxdg\_toplevel\_decoration_v1 interface description. Also, I would think that destroying the zxdg\_toplevel\_decoration\_manager\_v1 object while any zxdg\_toplevel\_decoration_v1 objects exist should be a client error, but this is similarly not specified anywhere.
> 
> The protocol integrates with the xdg-shell configuration mechanism, and I've been using the same wording as xdg-shell. xdg-toplevel-decoration just adds one property to the set of double-buffered xdg-surface properties (just like xdg-toplevel adds properties to xdg-surface). There are a bunch of "See xdg_surface.configure" in the description and as an extension of xdg-shell the protocol assumes the reader knows how xdg-shell works.

And it integrates rather well, IMO.
I have a few more comments that I will post on v2.

Thanks,

 > [snip]

-- 

Quentin “Sardem FF7” Glidic