Re: [PATCH wayland-protcols v2] unstable: add xdg-toplevel-decoration protocol

[Emil Velikov]

On 15 March 2018 at 15:43, Simon Ser  wrote:
> On March 15, 2018 4:15 PM, Emil Velikov  wrote:
>> On 2 March 2018 at 15:33, Simon Ser  wrote:
>> > This adds a new protocol to negotiate server- and client-side rendering of
>> > window decorations for xdg-toplevels. This allows compositors that want
>> > to draw decorations themselves to send their preference to clients, and
>> > clients that prefer server-side decorations to request them.
>> >
>> > This is inspired by a protocol from KDE [1] which has been implemented in
>> > KDE and Sway and was submitted for consideration in 2017 [2]. This patch
>> > provides an updated protocol with those concerns taken into account.
>> >
>> > Signed-off-by: Simon Ser 
>> > Reviewed-by: Drew DeVault 
>> > Reviewed-by: David Edmundson 
>> > Reviewed-by: Alan Griffiths 
>> > Reviewed-by: Tony Crisci 
>> >
>> More of a fly-by comment.
>>
>> Having a quick look does not list any of these R-B tags making it to the 
>> list.
>> Was it done in private, or I failed at searching?
>
> Yeah, it was done prior to submission to wayland-devel. See the commentary 
> below
> the commit message:
>
>> This was iterated on privately between representatives of Sway and wlroots
>> (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), and
>> Mir (Alan Griffiths).
>
Right, this says "iterated". Even then an official "Reviewed-by" ought
to happen in the open.

Anyway it was a JFYI
-Emil
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protcols v2] unstable: add xdg-toplevel-decoration protocol

[Simon Ser]

On March 15, 2018 4:15 PM, Emil Velikov  wrote:
> On 2 March 2018 at 15:33, Simon Ser  wrote:
> > This adds a new protocol to negotiate server- and client-side rendering of
> > window decorations for xdg-toplevels. This allows compositors that want
> > to draw decorations themselves to send their preference to clients, and
> > clients that prefer server-side decorations to request them.
> >
> > This is inspired by a protocol from KDE [1] which has been implemented in
> > KDE and Sway and was submitted for consideration in 2017 [2]. This patch
> > provides an updated protocol with those concerns taken into account.
> >
> > Signed-off-by: Simon Ser 
> > Reviewed-by: Drew DeVault 
> > Reviewed-by: David Edmundson 
> > Reviewed-by: Alan Griffiths 
> > Reviewed-by: Tony Crisci 
> >
> More of a fly-by comment.
> 
> Having a quick look does not list any of these R-B tags making it to the list.
> Was it done in private, or I failed at searching?

Yeah, it was done prior to submission to wayland-devel. See the commentary below
the commit message:

> This was iterated on privately between representatives of Sway and wlroots
> (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), and
> Mir (Alan Griffiths).

> If the former - it's very concerning practise.
>
> -Emil

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protcols v2] unstable: add xdg-toplevel-decoration protocol

[Emil Velikov]

On 2 March 2018 at 15:33, Simon Ser  wrote:
> This adds a new protocol to negotiate server- and client-side rendering of
> window decorations for xdg-toplevels. This allows compositors that want
> to draw decorations themselves to send their preference to clients, and
> clients that prefer server-side decorations to request them.
>
> This is inspired by a protocol from KDE [1] which has been implemented in
> KDE and Sway and was submitted for consideration in 2017 [2]. This patch
> provides an updated protocol with those concerns taken into account.
>
> Signed-off-by: Simon Ser 
> Reviewed-by: Drew DeVault 
> Reviewed-by: David Edmundson 
> Reviewed-by: Alan Griffiths 
> Reviewed-by: Tony Crisci 
>
More of a fly-by comment.

Having a quick look does not list any of these R-B tags making it to the list.
Was it done in private, or I failed at searching?

If the former - it's very concerning practise.

-Emil
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protcols v2] unstable: add xdg-toplevel-decoration protocol

[Simon Ser]

‐‐‐ Original Message ‐‐‐
On March 11, 2018 10:17 PM, Quentin Glidic  
wrote:
> ​​
> > 
> > > Last but not least: it should be much much clearer that the compositor
> > > is in charge here. This is not about magic SSD, clients must support CSD
> > > in all cases and should not error out if this global is not here. And
> > > even then, it may want CSD in some cases.
> > 
> > I've added this in the protocol description:
> > 
> > > Note that even if the server supports server-side window decorations, 
> > > clients
> > > must still support client-side decorations.
> 
> I think people already got that part, though it does no harm to say it
> again, but I was speaking about the configure event. It may happen atany time 
> and the client must be prepared (e.g for the cases you mentioned).

Right. Added:

A configure event can be sent at any time, not necessarily in reply to a
set_mode request.

Sending a v3 now.

> Cheers,
> 
> 
> -
> 
> Quentin “Sardem FF7” Glidic
> 
> wayland-devel mailing list
> 
> wayland-devel@lists.freedesktop.org
> 
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protcols v2] unstable: add xdg-toplevel-decoration protocol

[Quentin Glidic]

On 3/11/18 9:49 PM, Simon Ser wrote:

[snip]

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


You mention decorations only, but this (or some other text below maybe)
should mention shadows as well. You may consider them as part of the
decoration, but xdg_surface.set_window_geometry() is designed to include
decoration and exclude shadows. Yet, e.g. GTK+ allows to resize using
shadows IIRC.

Nit: I think GTK+ allows to move from any dead zone in the surface too. :-)


xdg-shell's wording includes drop-shadows as part of decorations:


Client-side decorations often have invisible portions like drop-shadows which
should be ignored for the purposes of aligning, placing and constraining
windows.


So "decorations" here stand for both visible parts such as the titlebar and
invisible parts such as drop-shadows. Do you think the protocol needs to
disambiguate these concepts?


You’re right, though I would rather be too precise (while not 
exhaustive) that not enough, just in case. But others may have a 
different opinion so let’s wait for more reviews here.




[snip]

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


This request I’m still not sure about it.
Why would an SSD-capable client would want to switch from CSD
back-and-forth? What is the use case here? (Preferably a user use case.)


One reason is consistency with xdg-shell.


Not all states can be client-initiated though.



But there are also real use-cases:
- A compositor might prefer SSDs or CSDs depending of the window container. For
   instance, a tiled compositor might prefer SSDs for tiled windows and CSDs for
   floating windows. Windows can be moved between a tiling and a floating
   container at run-time.


That I’m 100% ok with, your point is clear and makes a lot of sense. I 
would even object if someone wanted to remove that. :-)




- Clients might expose a user setting that allows toggling SSDs. For instance,
   Chrome/Chromium already has such a feature. Requiring the user to restart the
   app or to quickly close and reopen the main window offers poor UX.


I’m not convinced a client should have such a setting. For consistency 
and UX, I would rather have a central point of setting (the compositor). 
If we make it harder (though possible) to switch, then we can hopefully 
limit the number of clients wanting to support such a setting.
Since we must have the destructor support anyway, on both sides, I think 
it is enough for this feature.




[snip]

Last but not least: it should be much much clearer that the compositor
is in charge here. This is not about magic SSD, clients must support CSD
in all cases and should not error out if this global is not here. And
even then, it may want CSD in some cases.


I've added this in the protocol description:


Note that even if the server supports server-side window decorations, clients
must still support client-side decorations.


I think people already got that part, though it does no harm to say it 
again, but I was speaking about the configure event. It may happen *at 
any time* and the client must be prepared (e.g for the cases you mentioned).



Cheers,

--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protcols v2] unstable: add xdg-toplevel-decoration protocol

[Simon Ser]

On March 3, 2018 12:14 PM, Quentin Glidic  
wrote:
> On 3/2/18 4:33 PM, Simon Ser wrote:
> > This adds a new protocol to negotiate server- and client-side rendering of
> > window decorations for xdg-toplevels. This allows compositors that want
> > to draw decorations themselves to send their preference to clients, and
> > clients that prefer server-side decorations to request them.
> > 
> > This is inspired by a protocol from KDE [1] which has been implemented in
> > KDE and Sway and was submitted for consideration in 2017 [2]. This patch
> > provides an updated protocol with those concerns taken into account.
> > 
> > Signed-off-by: Simon Ser 
> > Reviewed-by: Drew DeVault 
> > Reviewed-by: David Edmundson 
> > Reviewed-by: Alan Griffiths 
> > Reviewed-by: Tony Crisci 
> > 
> > [1] 
> > https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml
> > [2] 
> > https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html
> 
> This is a nice protocol, and I would implement it (in clients) in its 
> current form, but I still have a few comments.

Thanks for your comments!

> > ---
> > 
> > This was iterated on privately between representatives of Sway and wlroots
> > (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson),
> > and Mir (Alan Griffiths).
> > 
> > A proof-of-concept of a client and server implementation is available at 
> > [1].
> > 
> > Changes from v1 to v2: moved the enum above in the protocol, added
> > Signed-off-by and Reviewed-by tags, updated the commit message.
> > 
> > [1] 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 000..e927110
> > --- /dev/null
> > +++ b/unstable/xdg-toplevel-decoration/README
> > @@ -0,0 +1,4 @@
> > +xdg_toplevel_decoration protocol
> > +
> > +Maintainers:
> > +Simon Ser 
> > 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 000..acc1ed2
> > --- /dev/null
> > +++ 
> > b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
> > @@ -0,0 +1,127 @@
> > +
> > +
> > +  
> > +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.
> > +  
> > +
> > +  
> > +
> > +  This interface 

Re: [PATCH wayland-protcols v2] unstable: add xdg-toplevel-decoration protocol

[Quentin Glidic]

On 3/2/18 4:33 PM, Simon Ser wrote:

This adds a new protocol to negotiate server- and client-side rendering of
window decorations for xdg-toplevels. This allows compositors that want
to draw decorations themselves to send their preference to clients, and
clients that prefer server-side decorations to request them.

This is inspired by a protocol from KDE [1] which has been implemented in
KDE and Sway and was submitted for consideration in 2017 [2]. This patch
provides an updated protocol with those concerns taken into account.

Signed-off-by: Simon Ser 
Reviewed-by: Drew DeVault 
Reviewed-by: David Edmundson 
Reviewed-by: Alan Griffiths 
Reviewed-by: Tony Crisci 

[1] 
https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml
[2] 
https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html


This is a nice protocol, and I would implement it (in clients) in its 
current form, but I still have a few comments.




---

This was iterated on privately between representatives of Sway and wlroots
(Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson),
and Mir (Alan Griffiths).

A proof-of-concept of a client and server implementation is available at [1].

Changes from v1 to v2: moved the enum above in the protocol, added
Signed-off-by and Reviewed-by tags, updated the commit message.

[1] 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 000..e927110
--- /dev/null
+++ b/unstable/xdg-toplevel-decoration/README
@@ -0,0 +1,4 @@
+xdg_toplevel_decoration protocol
+
+Maintainers:
+Simon Ser 
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 000..acc1ed2
--- /dev/null
+++ b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
@@ -0,0 +1,127 @@
+
+
+  
+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.
+  
+
+  
+
+  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.


You mention decorations only, but this (or some other text below maybe) 
should mention shadows as well. You may consider them as part of the 
decoration, but xdg_surface.set_window_geometry() is designed to include 
decoration and exclude shadows. Yet, e.g. GTK+ allows to resize using 
shadows IIRC.


Nit: I think GTK+ allows to move 

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

[Simon Ser]

This adds a new protocol to negotiate server- and client-side rendering of
window decorations for xdg-toplevels. This allows compositors that want
to draw decorations themselves to send their preference to clients, and
clients that prefer server-side decorations to request them.

This is inspired by a protocol from KDE [1] which has been implemented in
KDE and Sway and was submitted for consideration in 2017 [2]. This patch
provides an updated protocol with those concerns taken into account.

Signed-off-by: Simon Ser 
Reviewed-by: Drew DeVault 
Reviewed-by: David Edmundson 
Reviewed-by: Alan Griffiths 
Reviewed-by: Tony Crisci 

[1] 
https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml
[2] 
https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html
---

This was iterated on privately between representatives of Sway and wlroots
(Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson),
and Mir (Alan Griffiths).

A proof-of-concept of a client and server implementation is available at [1].

Changes from v1 to v2: moved the enum above in the protocol, added
Signed-off-by and Reviewed-by tags, updated the commit message.

[1] 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 000..e927110
--- /dev/null
+++ b/unstable/xdg-toplevel-decoration/README
@@ -0,0 +1,4 @@
+xdg_toplevel_decoration protocol
+
+Maintainers:
+Simon Ser 
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 000..acc1ed2
--- /dev/null
+++ b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
@@ -0,0 +1,127 @@
+
+
+  
+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.
+  
+
+  
+
+  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