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

[Simon Ser]

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.

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

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

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

> Regards,
> 
> Mike
> 
> On Thu, Mar 1, 2018 at 1:18 PM Simon Ser <contact at emersion.fr\> wrote:
> 
> > Hi Mike,
> > 
> > I don't think a compositor supporting the protocol means that it always wants SSDs. For instance, I can imagine a DE like GNOME supporting it:
> > 
> > - Allowing clients that prefer SSDs to use SSDs, so that toolkits like GLFW or winit and apps like mpv don't have to draw decorations that'll look alien and don't respect the user's preferences
> > - But still preferring CSDs, so that GTK+ apps can use them
> > 
> > Also, the CSD mode allows the client to do not draw decorations at all.
> > 
> > Regards,
> > 
> > On March 1, 2018 7:01 PM, Mike Blumenkrantz <michael.blumenkrantz at gmail.com\> wrote:
> > > Hi,
> > >
> > > This patch is certainly an improvement upon the previous protocol draft which I reviewed, but it still does not address the most significant issue that I pointed out, which is that it both is too complex and lacks features. Why is there any "mode" when this is a protocol for enabling server-side decorations? By using the protocol in a server or client, you are enabling server-side decoration; why would there be any mention of client-side at all? If the compositor, for whatever reason, decides to do a runtime disable of SSD then it can simply destroy the global.
> > >
> > > Please see again my mail on this topic from the previous thread: https://lists.freedesktop.org/archives/wayland-devel/2018-January/036495.html
> > >
> > > Regards,
> > >
> > > Mike