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