[PATCH wayland-protocols] unstable: add xdg-toplevel-decoration protocol
Mike Blumenkrantz
michael.blumenkrantz at gmail.com
Fri Mar 2 15:36:05 UTC 2018
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.
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.
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 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.
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.
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
> >
> > On Sun, Feb 18, 2018 at 3:01 PM Simon Ser <contact at emersion.fr\> wrote:
> >
> > > This adds a new protocol to negotiate server- and client-side
> rendering of
> > >
> > > window decorations for xdg-toplevels.
> > >
> > > \-\-\-
> > >
> > > This is inspired by a protocol from KDE\[0\] which has been
> implemented in KDE
> > >
> > > and Sway and was submitted for consideration in 2017\[1\]. This patch
> provides an
> > >
> > > updated protocol with those concerns taken into account.
> > >
> > > This was iterated on privately between representatives of Sway and
> wlroots
> > >
> > > (Simon Ser and Drew DeVault), KDE (David Edmundson), and Mir (Alan
> Griffiths).
> > >
> > > A proof-of-concept of a client and server implementation is available
> at \[2\].
> > >
> > > \[0\]
> https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml
> > >
> > > \[1\]
> https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html
> > >
> > > \[2\] https://github.com/swaywm/wlroots/pull/638
> > >
> > > Makefile.am | 1 +
> > >
> > > unstable/xdg-toplevel-decoration/README | 4 +
> > >
> > > .../xdg-toplevel-decoration-unstable-v1.xml | 127
> +++++++++++++++++++++
> > >
> > > 3 files changed, 132 insertions(+)
> > >
> > > create mode 100644 unstable/xdg-toplevel-decoration/README
> > >
> > > create mode 100644
> unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
> > >
> > > diff --git a/Makefile.am b/Makefile.am
> > >
> > > index 4b9a901..07744e9 100644
> > >
> > > \-\-\- a/Makefile.am
> > >
> > > \+\+\+ b/Makefile.am
> > >
> > > @@ -17,6 +17,7 @@ unstable_protocols =
> \
> > >
> > >
> unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
> \
> > >
> > > unstable/xdg-output/xdg-output-unstable-v1.xml
> \
> > >
> > > unstable/input-timestamps/input-timestamps-unstable-v1.xml
> \
> > >
> > > +
> unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
> \
> > >
> > > $(NULL)
> > >
> > > stable_protocols =
> \
> > >
> > > diff --git a/unstable/xdg-toplevel-decoration/README
> b/unstable/xdg-toplevel-decoration/README
> > >
> > > new file mode 100644
> > >
> > > index 0000000..e927110
> > >
> > > \-\-\- /dev/null
> > >
> > > \+\+\+ b/unstable/xdg-toplevel-decoration/README
> > >
> > > @@ -0,0 +1,4 @@
> > >
> > > +xdg\_toplevel\_decoration protocol
> > >
> > > +
> > >
> > > +Maintainers:
> > >
> > > +Simon Ser <contact at emersion.fr>
> > >
> > > diff --git
> a/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
> b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
> > >
> > > new file mode 100644
> > >
> > > index 0000000..acc1ed2
> > >
> > > \-\-\- /dev/null
> > >
> > > \+\+\+
> b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
> > >
> > > @@ -0,0 +1,127 @@
> > >
> > > +<?xml version="1.0" encoding="UTF-8"?>
> > >
> > > +<protocol name="xdg\_toplevel\_decoration\_unstable\_v1">
> > >
> > > + <copyright>
> > >
> > > + Copyright © 2018 Simon Ser
> > >
> > > +
> > >
> > > + Permission is hereby granted, free of charge, to any person
> obtaining a
> > >
> > > + copy of this software and associated documentation files (the
> "Software"),
> > >
> > > + to deal in the Software without restriction, including without
> limitation
> > >
> > > + the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> > >
> > > + and/or sell copies of the Software, and to permit persons to whom
> the
> > >
> > > + Software is furnished to do so, subject to the following
> conditions:
> > >
> > > +
> > >
> > > + The above copyright notice and this permission notice (including
> the next
> > >
> > > + paragraph) shall be included in all copies or substantial
> portions of the
> > >
> > > + Software.
> > >
> > > +
> > >
> > > + THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> > >
> > > + IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> > >
> > > + FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
> EVENT SHALL
> > >
> > > + THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES
> OR OTHER
> > >
> > > + LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> ARISING
> > >
> > > + FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> OTHER
> > >
> > > + DEALINGS IN THE SOFTWARE.
> > >
> > > + </copyright>
> > >
> > > +
> > >
> > > + <interface name="zxdg\_toplevel\_decoration\_manager\_v1"
> version="1">
> > >
> > > + <description summary="window decoration manager">
> > >
> > > + This interface permits choosing between client-side and
> server-side
> > >
> > > + window decorations for a toplevel surface.
> > >
> > > +
> > >
> > > + A window decoration is a user interface component used to move,
> resize and
> > >
> > > + change a window's state. It can be managed either by the client
> (part of
> > >
> > > + the surface) or by the server.
> > >
> > > +
> > >
> > > + By advertizing this interface the server anounces support for
> server-side
> > >
> > > + window decorations.
> > >
> > > +
> > >
> > > + Warning! The protocol described in this file is experimental and
> > >
> > > + backward incompatible changes may be made. Backward compatible
> changes
> > >
> > > + may be added together with the corresponding interface version
> bump.
> > >
> > > + Backward incompatible changes are done by bumping the version
> number in
> > >
> > > + the protocol and interface names and resetting the interface
> version.
> > >
> > > + Once the protocol is to be declared stable, the 'z' prefix and
> the
> > >
> > > + version number in the protocol and interface names are removed
> and the
> > >
> > > + interface version number is reset.
> > >
> > > + </description>
> > >
> > > +
> > >
> > > + <enum name="error">
> > >
> > > + <entry name="unconfigured_buffer" value="1"/>
> > >
> > > + <entry name="already_constructed" value="2"/>
> > >
> > > + </enum>
> > >
> > > +
> > >
> > > + <request name="destroy" type="destructor">
> > >
> > > + <description summary="destroy the decoration manager object">
> > >
> > > + Destroy the decoration manager.
> > >
> > > + </description>
> > >
> > > + </request>
> > >
> > > +
> > >
> > > + <request name="get_decoration">
> > >
> > > + <description summary="create a new decoration object">
> > >
> > > + Create a new decoration object associated with the given
> toplevel.
> > >
> > > +
> > >
> > > + Creating a zxdg\_toplevel\_decoration\_v1 from a
> xdg\_toplevel which has a
> > >
> > > + buffer attached or committed is a client error, and any
> attempts by a
> > >
> > > + client to attach or manipulate a buffer prior to the first
> > >
> > > + zxdg\_toplevel\_decoration_v1.configure call must also be
> treated as
> > >
> > > + errors.
> > >
> > > + </description>
> > >
> > > + <arg name="id" type="new\_id"
> interface="zxdg\_toplevel\_decoration\_v1"/>
> > >
> > > + <arg name="toplevel" type="object" interface="xdg_toplevel"/>
> > >
> > > + </request>
> > >
> > > + </interface>
> > >
> > > +
> > >
> > > + <interface name="zxdg\_toplevel\_decoration_v1" version="1">
> > >
> > > + <description summary="decoration object for a toplevel surface">
> > >
> > > + The decoration object allows the client to switch between a
> client-side
> > >
> > > + and server-side window decoration for a toplevel surface.
> > >
> > > + </description>
> > >
> > > +
> > >
> > > + <request name="destroy" type="destructor">
> > >
> > > + <description summary="destroy the decoration object">
> > >
> > > + Switch back to client-side-only window decoration mode.
> > >
> > > + </description>
> > >
> > > + </request>
> > >
> > > +
> > >
> > > + <request name="set_mode">
> > >
> > > + <description summary="set the decoration mode">
> > >
> > > + Set the toplevel surface decoration mode.
> > >
> > > +
> > >
> > > + After requesting a decoration mode, the compositor will
> respond by
> > >
> > > + emitting a xdg_surface.configure event. The client should
> then update
> > >
> > > + its content, drawing it with or without decorations depending
> on the
> > >
> > > + received mode. The client must also acknowledge the configure
> when
> > >
> > > + committing the new content (see xdg\_surface.ack\_configure).
> > >
> > > +
> > >
> > > + The compositor can ignore this request.
> > >
> > > + </description>
> > >
> > > + <arg name="mode" type="uint" enum="mode" summary="the
> decoration mode"/>
> > >
> > > + </request>
> > >
> > > +
> > >
> > > + <event name="preferred_mode">
> > >
> > > + <description summary="advertise the server's preferred mode">
> > >
> > > + The preferred_mode event describes the server's preferred
> decoration
> > >
> > > + mode for this toplevel surface. The event is sent when
> binding to the
> > >
> > > + decoration object and whenever the preferred mode changes.
> > >
> > > + </description>
> > >
> > > + <arg name="mode" type="uint" enum="mode" summary="the preferred
> mode"/>
> > >
> > > + </event>
> > >
> > > +
> > >
> > > + <event name="configure">
> > >
> > > + <description summary="suggest a surface change">
> > >
> > > + The configure event asks the client to change its decoration
> mode. The
> > >
> > > + configured state should not be applied immediately. See
> > >
> > > + xdg_surface.configure for details.
> > >
> > > + </description>
> > >
> > > + <arg name="mode" type="uint" enum="mode" summary="the
> decoration mode"/>
> > >
> > > + </event>
> > >
> > > +
> > >
> > > + <enum name="mode">
> > >
> > > + <description summary="window decoration modes">
> > >
> > > + These values describe window decoration modes.
> > >
> > > + </description>
> > >
> > > + <entry name="client" value="1" summary="client-side window
> decoration"/>
> > >
> > > + <entry name="server" value="2" summary="server-side window
> decoration"/>
> > >
> > > + </enum>
> > >
> > > + </interface>
> > >
> > > +</protocol>
> > >
> > > --
> > >
> > > 2.16.1
> > >
> > >
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
> > >
> > > wayland-devel mailing list
> > >
> > > wayland-devel at lists.freedesktop.org
> > >
> > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180302/8583bfa4/attachment-0001.html>
More information about the wayland-devel
mailing list