(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.blumenkra...@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
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
