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

[Simon Ser]

On March 22, 2018 2:39 PM, Simon McVittie  wrote:
> Those dialogs still have all the window-management operation widgets that
> the application designer wants them to have - that just happens to mean
> "none" in this case.
> 
> Contrast with the same dialogs in a SSD environment, where they get all
> the window-management operation widgets that the *window manager*
> designer wants them to have (which might be different).

What I want to say is that in SSD mode, requiring clients not to draw window
management widgets allows them to draw decorations not useful for window
management such as shadows and rounded corners, which is not what we want.
Meanwhile, requiring clients not to draw decorations in SSD mode prevents them
from drawing these and is really what we want.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Simon McVittie]

On Thu, 22 Mar 2018 at 08:22:23 -0400, Simon Ser wrote:
> I think we really do mean "decorations" and not "window management". 
> Decorations
> are used for window management, but their scope is larger - they are also user
> interface components.
> 
> For instance, I can think of GNOME [1] and elementary OS' [2] dialogs, which 
> do
> have decorations (rounded corners, shadows) but for which decorations cannot 
> be
> used for window management operations (they are purely aesthetic).

Those dialogs still have all the window-management operation widgets that
the application designer wants them to have - that just happens to mean
"none" in this case.

Contrast with the same dialogs in a SSD environment, where they get all
the window-management operation widgets that the *window manager*
designer wants them to have (which might be different).

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

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

[Simon Ser]

On March 22, 2018 6:37 AM, Peter Hutterer  wrote:
> so, random thought: instead of talking about decorations or not (which isn't
> what we really care about) talk about window management and who does it.

I think we really do mean "decorations" and not "window management". Decorations
are used for window management, but their scope is larger - they are also user
interface components.

For instance, I can think of GNOME [1] and elementary OS' [2] dialogs, which do
have decorations (rounded corners, shadows) but for which decorations cannot be
used for window management operations (they are purely aesthetic).

So the client drawing these dialogs and not using SSDs doesn't provide any
window management operation widget, but at the same time draws decorations. Such
a client using SSDs (via the decoration protocol) probably shouldn't draw
rounded corners nor shadows.

That's why I think using the "SSD/no SSD" vocabulary is more accurate. What do
you think?

[1] https://developer.gnome.org/hig/stable/dialogs.html.en#message-dialogs
[2] https://elementary.io/docs/human-interface-guidelines#dialogs

​---
Simon Ser
https://emersion.fr​

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

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

[Peter Hutterer]

On Mon, Mar 19, 2018 at 04:59:15AM +0900, Eike Hein wrote:
> 
> >> If server and client do not negotiate the use of a server-side
> >> decoration using this protocol, clients continue to self-decorate as
> >> they see fit."
> >
> > The wording here is weird, and I want to avoid the word decorate. What
> > the client does is not necessarily decorate. The reason why clients
> > would need to decorate themselves at all is to give the user some visual
> > cues for their true purpose: window management. We should just say this.
> > I prefer my previous wording:
> >
> >> If the client chooses not to use server-side decorations, it is
> >> responsible for its own window management operations.
> Up-front: I could live with that one if need be.
> 
> ... but I think it's sort of inviting some trouble again. "Window
> management operations" gets us - albeit in a much less specific way,
> which is a big improvement - back into the territory of defining
> "decoration". The use of "responsible" also creates an expectation that
> a client will cater to window management in some way, which some clients
> have shown a preference for not doing. I think my version captures
> reality in a better way without holding anyone to new requirements that
> didn't exist before today.
>
> The spirit of my para was two communicate two things:
> 
> * This is an optional additional negotiation that takes place between
> server and client that allows them to agree on the client being
> server-decorated.
> 
> That means servers who don't care are unaffected and clients which don't
> care are unaffected, which is what we want because we can't universally
> agree on any specific case, but we can agree that Wayland should let us
> all build the systems we envision. What it does allow is for components
> that do agree to work together, which is a big step in the right direction.
> 
> * If this negotiation does not take place or does not have this result
> (server does not implement at all, preferred mode is client-side, client
> doesn't request server-side), clients are left to do whatever.
> 
> The wording of my second clause also implies - but does not enforce,
> since it has no mechanism to do this anyway - that if client and server
> agree on server-side decoration, a client should probably not decorate,
> which I think is good to have in there in spirit.

so, random thought: instead of talking about decorations or not (which isn't
what we really care about) talk about window management and who does it.
So you now name it xdg-toplevel-window-management and the two options you
get are
* self-managed: the client is expected to control window operations such as
  move, resize, minimize and maximize and closing windows. The exact
  approach is client-dependent, usually clients provided a window decoration
  bar with GUI elements to perform some of these tasks.
  Clients are not required to provide any or all above operations on all
  windows, they may provide window management operations not listed in
  the above enumeration, or they may not provide any graphical elements for
  these tasks.
* imposed: window operations such as move, resize, ... are imposed on the
  client by the compositor. The client should avoid rendering GUI elements
  for these operations, these should be provided by the compositor instead.

I think this covers the current case well enough (self-managed) and is
explicit enough about the SSD case and the expectations. Some wording
improvements may be needed.

Just as an extra note: the term "imposed" is chosen explicitly - once a
compositor says it's going to decorate the window, the client loses all
information about which operations are available to the user. In some
clients this may result in a detrimental user experience (e.g. if a maximise
button isn't there that the client really really expects). But such is life
under an imposing rule ;)

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

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

[Pekka Paalanen]

On Sun, 18 Mar 2018 14:59:58 -0400
Simon Ser  wrote:

> On March 16, 2018 1:22 PM, Pekka Paalanen  wrote:
> > > > I'm missing a comment that describes what happens if the xdg_toplevel is
> > > > destroyed. There is some object dependency here that needs to be 
> > > > stated. Do
> > > > we need an event here? Or are we assuming that clients are smart enough 
> > > > to
> > > > keep track of destroy events. Either way - needs to be explicitly 
> > > > stated.
> > > 
> > > What about requiring clients to destroy the zxdg_toplevel_decoration_v1 
> > > before
> > > the xdg_toplevel?  
> > 
> > Hi,
> > 
> > you can, but then you need an error code for clients that get it wrong.
> > 
> > A common convention is to instead say that zxdg_toplevel_decoration_v1
> > becomes "inert" when the associated xdg_toplevel is destroyed. It means
> > the object will not send any events, and all requests except destroy
> > will be ignored. This approach is often used with racy cases where
> > requiring a single order of actions is not possible, and it comes with
> > the disadvantage of needing to define what happens if you pass an inert
> > object of this type as an argument in some other interface, or if the
> > inert object had requests that create more objects.  
> 
> Thanks for the explanation!
> 
> > Both ways are possible. You may want to check how xdg_toplevel deals
> > with xdg_surface destruction and how xdg_surface deals with wl_surface
> > destruction. Maybe consistency would be the best plan?  
> 
> The protocol states that: "An xdg_surface must only be destroyed after its 
> role
> object has been destroyed". But it doesn't define any error type for protocol
> violations. I didn't find anything about the relationship between xdg_surface
> and xdg_surface.
> 
> So I'm not sure what to do to be consistent with xdg-shell. The options are:
> - Become inert
> - Send an error on the decoration object
> - Automatically destroying the decoration when the toplevel is destroyed?
> 
> I'll just go with becoming inert for now. Let me know what you think.

Hi,

I'd just like to point out that the third option to automatically
destroy the object is not a good option. If a client first destroys
xdg_toplevel and that causes the server to internally destroy the
decoration object, then the client will either cause a protocol error
with destroying the decoration object (you have protocol for destroy
request, and the request will refer to an object that does not exist in
the server anymore), or the decoration object needs to have two kinds of
destroy functions: one that sends destroy request (I assume there are
use cases which do want it) and another that does not, plus the client
needs to be careful to use the right one. So to me that seems like the
worst option.

It's always dangerous for a server to automatically destroy a protocol
object, if the object interface has any requests defined. It would need
very careful design and use to avoid protocol error inducing races or
conditions, so I would advice against it.

A destroy request is a request. Where we often have the server
automatically destroy an object are interfaces which essentially act as
a "return value" delivery, and therefore do not have requests defined.
These objects must also never be used as arguments in any requests, or
you fall into the can of worms again.

I forget what the decoration interface spec says, but if you have a
defined consequence from destroying the protocol object, e.g. while the
window is still mapped, you need to consider if that may cause a
user visible glitch. You cannot assume that sequential requests are
handled together, it is possible the compositor can go do something else
between *any* two requests. But because usually compositors don't and
clients flush out requests in bursts, it is very unlikely to see the
glitch problems in normal testing. You would need to use a protocol
debugger that added an explicit flush and delay between every single
request and event.

I hope this helps you decide on a better design.


Thanks,
pq


pgpwTFWXcL8pK.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Peter Hutterer]

On Wed, Mar 14, 2018 at 06:41:53AM -0400, Simon Ser wrote:
> On March 14, 2018 10:22 AM, Peter Hutterer  wrote:
> > sorry about the delay, but better late than too late ;)
> 
> No problem, thanks for your review!
> 
> > On Sun, Mar 11, 2018 at 05:53:42PM -0400, 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 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 v2 to v3: fix typos, clarify xdg_toplevel_decoration.destroy
> > > semantics, clarify that clients always need to support CSD and can receive
> > > configure events at any time.
> > > 
> > > [1] https://github.com/swaywm/wlroots/pull/638
> > > 
> > >  Makefile.am|   1 +
> > >  unstable/xdg-toplevel-decoration/README|   4 +
> > >  .../xdg-toplevel-decoration-unstable-v1.xml| 132 
> > > +
> > >  3 files changed, 137 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..a34cb73
> > > --- /dev/null
> > > +++ 
> > > b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
> > > @@ -0,0 +1,132 @@
> > > +
> > > +
> > > +  
> > > +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 

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

[Drew DeVault]

How about:

If the client chooses not to use server-side decorations, it may be
responsible for its own window management operations.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Eike Hein]

>> If server and client do not negotiate the use of a server-side
>> decoration using this protocol, clients continue to self-decorate as
>> they see fit."
>
> The wording here is weird, and I want to avoid the word decorate. What
> the client does is not necessarily decorate. The reason why clients
> would need to decorate themselves at all is to give the user some visual
> cues for their true purpose: window management. We should just say this.
> I prefer my previous wording:
>
>> If the client chooses not to use server-side decorations, it is
>> responsible for its own window management operations.
Up-front: I could live with that one if need be.

... but I think it's sort of inviting some trouble again. "Window
management operations" gets us - albeit in a much less specific way,
which is a big improvement - back into the territory of defining
"decoration". The use of "responsible" also creates an expectation that
a client will cater to window management in some way, which some clients
have shown a preference for not doing. I think my version captures
reality in a better way without holding anyone to new requirements that
didn't exist before today.

The spirit of my para was two communicate two things:

* This is an optional additional negotiation that takes place between
server and client that allows them to agree on the client being
server-decorated.

That means servers who don't care are unaffected and clients which don't
care are unaffected, which is what we want because we can't universally
agree on any specific case, but we can agree that Wayland should let us
all build the systems we envision. What it does allow is for components
that do agree to work together, which is a big step in the right direction.

* If this negotiation does not take place or does not have this result
(server does not implement at all, preferred mode is client-side, client
doesn't request server-side), clients are left to do whatever.

The wording of my second clause also implies - but does not enforce,
since it has no mechanism to do this anyway - that if client and server
agree on server-side decoration, a client should probably not decorate,
which I think is good to have in there in spirit.



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

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

[Drew DeVault]

On 2018-03-19  4:42 AM, Eike Hein wrote:
> How about:
> 
> 
> 

+1

> And as description:
> 
> "This interface allows a server to announce support for server-side
> decorations and optionally express a preference for using them.
> 
> A client can use this protocol to request being decorated by a
> supporting server.

+1

> If server and client do not negotiate the use of a server-side
> decoration using this protocol, clients continue to self-decorate as
> they see fit."

The wording here is weird, and I want to avoid the word decorate. What
the client does is not necessarily decorate. The reason why clients
would need to decorate themselves at all is to give the user some visual
cues for their true purpose: window management. We should just say this.
I prefer my previous wording:

> If the client chooses not to use server-side decorations, it is
> responsible for its own window management operations.

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

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

[Eike Hein]

How about:




And as description:

"This interface allows a server to announce support for server-side
decorations and optionally express a preference for using them.

A client can use this protocol to request being decorated by a
supporting server.

If server and client do not negotiate the use of a server-side
decoration using this protocol, clients continue to self-decorate as
they see fit."

Cheers,
Eike


On 03/19/2018 04:34 AM, Drew DeVault wrote:
> To summarize the state of affairs here, the purpose of this protocol is
> to communicate:
> 
> - The compositor's preference to use SSD or leave the client to its own
>   devices
> - The choice of the client to have SSD displayed
> 
> We can completely remove CSD from the question because the term is
> barely meaningful. CSD is just a code-word for "some client-provided
> mechanism for window manipulation". SSD on the other hand is an apt
> description for what the server is going to do here.
> 
> I think we can settle the matter by making the following change to
> Simon's proposal:
> 
> 
>   
> These values describe window decoration modes.
>   
> - 
> - 
> + 
> + 
> 
> 
> Then updating the prose accordingly. We can include a note along the
> lines of "if the client chooses not to use server-side decorations, it
> is responsible for its own window management operations."
> 
> --
> Drew DeVault
> 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Drew DeVault]

To summarize the state of affairs here, the purpose of this protocol is
to communicate:

- The compositor's preference to use SSD or leave the client to its own
  devices
- The choice of the client to have SSD displayed

We can completely remove CSD from the question because the term is
barely meaningful. CSD is just a code-word for "some client-provided
mechanism for window manipulation". SSD on the other hand is an apt
description for what the server is going to do here.

I think we can settle the matter by making the following change to
Simon's proposal:


  
These values describe window decoration modes.
  
- 
- 
+ 
+ 


Then updating the prose accordingly. We can include a note along the
lines of "if the client chooses not to use server-side decorations, it
is responsible for its own window management operations."

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

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

[Simon Ser]

On March 16, 2018 1:22 PM, Pekka Paalanen  wrote:
> > > I'm missing a comment that describes what happens if the xdg_toplevel is
> > > destroyed. There is some object dependency here that needs to be stated. 
> > > Do
> > > we need an event here? Or are we assuming that clients are smart enough to
> > > keep track of destroy events. Either way - needs to be explicitly stated. 
> > >  
> > 
> > What about requiring clients to destroy the zxdg_toplevel_decoration_v1 
> > before
> > the xdg_toplevel?
> 
> Hi,
> 
> you can, but then you need an error code for clients that get it wrong.
> 
> A common convention is to instead say that zxdg_toplevel_decoration_v1
> becomes "inert" when the associated xdg_toplevel is destroyed. It means
> the object will not send any events, and all requests except destroy
> will be ignored. This approach is often used with racy cases where
> requiring a single order of actions is not possible, and it comes with
> the disadvantage of needing to define what happens if you pass an inert
> object of this type as an argument in some other interface, or if the
> inert object had requests that create more objects.

Thanks for the explanation!

> Both ways are possible. You may want to check how xdg_toplevel deals
> with xdg_surface destruction and how xdg_surface deals with wl_surface
> destruction. Maybe consistency would be the best plan?

The protocol states that: "An xdg_surface must only be destroyed after its role
object has been destroyed". But it doesn't define any error type for protocol
violations. I didn't find anything about the relationship between xdg_surface
and xdg_surface.

So I'm not sure what to do to be consistent with xdg-shell. The options are:
- Become inert
- Send an error on the decoration object
- Automatically destroying the decoration when the toplevel is destroyed?

I'll just go with becoming inert for now. Let me know what you think.

> Thanks,
> pq

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

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

[Daniel Stone]

Hi Eike,

On 18 March 2018 at 16:35, Eike Hein  wrote:
> On 03/18/2018 03:55 PM, Markus Ongyerth wrote:
>>> a) Change the definition of "decoration" to "window controls as deemed
>>> appropriate by the compositor, for example ...". This leaves what's in a
>>> server-side deco and what's in a client-side deco up to servers and
>>> clients, respectively, and allows this protocol to serve more systems.
>> While a bit of rewording here (probably to the ambigous state it's in
>> xdg-shell) wouldn't hurt, this particular sentence would make CSD very weird,
>> since the client doesn't know what the compositor deems appropriate.
>> I think we should avoid the situation where clients try to guess their env,
>> not promote it even further.
>
> I hear you, but I don't think it's a problem - hang on.
>
> Let's try to cut through all the heated contention we've had going on:
> One of the issues some people in the "SSD camp" have is that in their
> minds, "CSD" means whatever GTK+ 3 is doing with header bars, since
> that's the most prominent example around.
>
> But in a wayland-devel context, to paraphrase someone from #wayland, CSD
> actually just means "the client is expected to draw whatever decoration
> it deems fit for its uses" (which could include "nothing at all").
>
> So you have two different models of thought:
>
> a) Systems where the compositor wants to put standardized decorations on
> clients to enforce/enable particular behavior and/or workflow across all
> of them.
>
> b) Systems where the compositor takes the stance of "the client knows
> best how it wants to decorate itself".
>
> In my eyes this protocol is about negotiating between these two cases,
> and that's where my proposed wording comes from. If the server
> advertises this interface, a client can opt into "I agree I'm not going
> to decorate myself and let you do it", or the client can be left to its
> own devices.
>
> I think in both case, the protocol shouldn't make any attempts at
> specifying what either the server or the client should put into a
> decoration, which is what the text does right now. I think it's both
> unnecessary and constrains us in a way we don't actually want. This
> should be removed from the protocol text.

This is a really good and useful definition, and I couldn't agree
more. I don't think language-lawyering about exactly what constitutes
decorations is going to help. (After all, one of the big demands for
this is tiling window managers, some of which currently abuse the
maximised state ...)

> Plus, there's a chance here to go 180 degrees from the current wording
> and describe the non-server-decorated case as "client shall decorate
> itself as it sees fit" explicitly, which is obvious to some of the
> Wayland community but not all, and could help with finally putting all
> this in-fighting behind us. Without introducing any new side-effects in
> the process (I think that's a free bonus, mind you - the main motivation
> is just engineering hygiene).

Works for me. Given how apparent it was from IRC that people were
misinterpreting each other's positions, I think explaining it from the
compositor point of view would be ideal. Let's see what the others
think.

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

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

[Daniel Stone]

Hi,

On 18 March 2018 at 16:22, Eike Hein  wrote:
> On 03/18/2018 10:45 PM, Daniel Stone wrote:
>> That strikes me as a problem. So what can we do to bridge the gap
>> between these projects?
>
> FWIW, I agree this is a problem. KDE's Wayland contributor base is
> slowly growing, though - we have more people working on Wayland stuff
> than we had previously, and across more products which rely on it
> exclusively (e.g. Plasma Mobile) - and I'm optimistic this is going to
> lead to us talking more, talking earlier, and taking more responsibility
> for shepherding the stack, together.
>
> I'm also wondering if a shared "Planet Wayland" blog aggregator would
> make sense, and subscribing implementers from across the community to it
> - currently you have to take some more active steps to follow content
> published by people who solve interesting problems with Wayland, and
> regretably, perhaps the best way to discover them is whenever they cause
> drama on r/linux. That's a rather poor state of affairs.

Yeah, that's a good one. One other suggestion was that we should
document the review process: both setting expectations for
contributors, and also helping to gain new reviewers by making it
clear how best to review. As well as having something documented that
the whole community can agree on and hold each other to, rather than
undocumented lore.

Having a much better documentation base and website would be great as well.

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

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

[Eike Hein]

On 03/18/2018 03:55 PM, Markus Ongyerth wrote:
>> a) Change the definition of "decoration" to "window controls as deemed
>> appropriate by the compositor, for example ...". This leaves what's in a
>> server-side deco and what's in a client-side deco up to servers and
>> clients, respectively, and allows this protocol to serve more systems.
> While a bit of rewording here (probably to the ambigous state it's in 
> xdg-shell) wouldn't hurt, this particular sentence would make CSD very weird, 
> since the client doesn't know what the compositor deems appropriate.
> I think we should avoid the situation where clients try to guess their env, 
> not promote it even further.

I hear you, but I don't think it's a problem - hang on.

Let's try to cut through all the heated contention we've had going on:
One of the issues some people in the "SSD camp" have is that in their
minds, "CSD" means whatever GTK+ 3 is doing with header bars, since
that's the most prominent example around.

But in a wayland-devel context, to paraphrase someone from #wayland, CSD
actually just means "the client is expected to draw whatever decoration
it deems fit for its uses" (which could include "nothing at all").

So you have two different models of thought:

a) Systems where the compositor wants to put standardized decorations on
clients to enforce/enable particular behavior and/or workflow across all
of them.

b) Systems where the compositor takes the stance of "the client knows
best how it wants to decorate itself".

In my eyes this protocol is about negotiating between these two cases,
and that's where my proposed wording comes from. If the server
advertises this interface, a client can opt into "I agree I'm not going
to decorate myself and let you do it", or the client can be left to its
own devices.

I think in both case, the protocol shouldn't make any attempts at
specifying what either the server or the client should put into a
decoration, which is what the text does right now. I think it's both
unnecessary and constrains us in a way we don't actually want. This
should be removed from the protocol text.

Plus, there's a chance here to go 180 degrees from the current wording
and describe the non-server-decorated case as "client shall decorate
itself as it sees fit" explicitly, which is obvious to some of the
Wayland community but not all, and could help with finally putting all
this in-fighting behind us. Without introducing any new side-effects in
the process (I think that's a free bonus, mind you - the main motivation
is just engineering hygiene).


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

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

[Eike Hein]

On 03/18/2018 10:45 PM, Daniel Stone wrote:
> That strikes me as a problem. So what can we do to bridge the gap
> between these projects?

FWIW, I agree this is a problem. KDE's Wayland contributor base is
slowly growing, though - we have more people working on Wayland stuff
than we had previously, and across more products which rely on it
exclusively (e.g. Plasma Mobile) - and I'm optimistic this is going to
lead to us talking more, talking earlier, and taking more responsibility
for shepherding the stack, together.

I'm also wondering if a shared "Planet Wayland" blog aggregator would
make sense, and subscribing implementers from across the community to it
- currently you have to take some more active steps to follow content
published by people who solve interesting problems with Wayland, and
regretably, perhaps the best way to discover them is whenever they cause
drama on r/linux. That's a rather poor state of affairs.


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

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

[Markus Ongyerth]

Sorry, I messed up my quoting, cutting down the mail =.=

I wanted to keep the part that ended in:

> Yes, but I think this reinforces my point. If an IVI, phone or
> set-top-box compositor suddenly started sticking decorations on the
> surfaces it found, it wouldn't be useful. Saying 'but the clients
> never asked _not_ to be decorated' wouldn't really help you get out of
> it either.
Which is in a specialised environment that usually wants no deco (probably 
fullscreen shell by default etc.) but may run xdg-shell for reasons.

On 2018/3月/18 03:40, Markus Ongyerth wrote:
> On 2018/3月/18 01:45, Daniel Stone wrote:
> > Hi Drew,
> > 
> > On 15 March 2018 at 16:53, Drew DeVault  wrote:
> > >> > In fact, I have done so. Before we started working on this protocol,
> > >> > Sway did exactly this. We have provided users the means of overriding
> > >> > the approach to decorations, including what ends up being double
> > >> > decorations sometimes.
> > >>
> > >> OK, but that doesn't seem like the kind of user experience to aim for 
> > >> ... ?
> > >
> > > Yeah, it's not ideal. The impetus for this protocol is to solve this
> > > problem by getting software written by both camps to negotiate. It's
> > > clear we're not going to get either side to agree to buy into the other,
> > > so in the interests of the user we're trying to accomodate both.
> > 
> > I understand that, and the compromise is good. But my view here is
> > that compositors sticking server-side decorations on unwilling clients
> > are the ones upsetting the status quo. Your view seems to be that
> > there _is_ no status quo, so either approach is equally valid in the
> > absence of explicit negotiation.
> I think we have quite different ideas of what this situation would look like.
> The (specialised) compositor doing things that don't fit it's environment is 
> something I wouldn't expect.
> 
> If a set-top-box or phone wanted to run e.g. gvim it wouldn't want that to 
> draw it's own decorations, which it would do in the normal case.
> And if a specialised application was run on a "normal desktop" compositor 
> (for 
> whatever reason), the provided SSD would be the easiest way for it to support 
> this. (I kind of doubt they use xdg-shell for those though)
> 
> I'm interested in where this disparity in worries stems from.
> Do you go by the asumption that the compositor might change in these 
> settings, 
> while the clients stay specialised?
> 
> Cheers,
> ongy




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

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

[Markus Ongyerth]

On 2018/3月/18 01:45, Daniel Stone wrote:
> Hi Drew,
> 
> On 15 March 2018 at 16:53, Drew DeVault  wrote:
> >> > In fact, I have done so. Before we started working on this protocol,
> >> > Sway did exactly this. We have provided users the means of overriding
> >> > the approach to decorations, including what ends up being double
> >> > decorations sometimes.
> >>
> >> OK, but that doesn't seem like the kind of user experience to aim for ... ?
> >
> > Yeah, it's not ideal. The impetus for this protocol is to solve this
> > problem by getting software written by both camps to negotiate. It's
> > clear we're not going to get either side to agree to buy into the other,
> > so in the interests of the user we're trying to accomodate both.
> 
> I understand that, and the compromise is good. But my view here is
> that compositors sticking server-side decorations on unwilling clients
> are the ones upsetting the status quo. Your view seems to be that
> there _is_ no status quo, so either approach is equally valid in the
> absence of explicit negotiation.
I think we have quite different ideas of what this situation would look like.
The (specialised) compositor doing things that don't fit it's environment is 
something I wouldn't expect.

If a set-top-box or phone wanted to run e.g. gvim it wouldn't want that to 
draw it's own decorations, which it would do in the normal case.
And if a specialised application was run on a "normal desktop" compositor (for 
whatever reason), the provided SSD would be the easiest way for it to support 
this. (I kind of doubt they use xdg-shell for those though)

I'm interested in where this disparity in worries stems from.
Do you go by the asumption that the compositor might change in these settings, 
while the clients stay specialised?

Cheers,
ongy


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

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

[Drew DeVault]

On 2018-03-18  1:45 PM, Daniel Stone wrote:
> I don't think prolonging the argument is helpful. Just a fairly clear
> statement that in the absence of this extension and unless told
> otherwise, clients which can decorate themselves, should decorate
> themselves, would work for me. I don't want to be painted into a
> corner where clients _can_ decorate themselves, but do not because the
> compositor does not advertise an extension which requires it to be
> able to decorate other clients. Peter and Pekka had some good comments
> on a more technical level as well.

I haven't been convinced by your arguments, but I also don't think
there's anything more to say. We'll add whatever prose you want on the
subject of mandatory CSD to the protocol. We've always been able to
abuse the letter of the law to get what we want anyway - sway sets all
windows to maximized so they listen to our pleas for being sized a
particular way, for example. I'm sure that clients that don't want to
implement CSD will continue not to no matter what we put in the
protocol.

I think Simon is working on a v4 patch that should incoporate the
technical feedback and I guess will find a place to mention that CSDs
are mandatory.

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

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

[Daniel Stone]

Hi Drew,

On 15 March 2018 at 16:53, Drew DeVault  wrote:
>> Denying facts and being disingenuous doesn't help anyone, and it's
>> tiring. Tiring enough that I came into this thread with the intention
>> of giving this protocol a couple of suggestions and a push towards
>> getting it merged, because I'm tired of the totally counterproductive
>> division between wlc/wlroots/Sway/mpv and the rest of the Wayland
>> world, but I've lost all motivation to continue.
>
> This is not something wlc/wlroots/sway/mpv is pushing for alone. This
> thread represents the opinions of several major players in the Wayland
> ecosystem: Sway, KDE, Mir, Way Cooler, waymonad, and bspwc are all
> represented here. Given this, it's difficult for me to accept that a
> consensus has been reached.

Unfortunately it's exceedingly rare to hear from all these projects
either on the list or IRC. I did know that KDE had implemented it,
because Martin mentioned it in a throwaway comment once. I had a vague
recollection that WLC/wlroots also implemented it, and no idea about
the rest (bspwc is something I had literally not heard of until
today).

That strikes me as a problem. So what can we do to bridge the gap
between these projects?

> It is my intention to earnestly express the opinion of our projects and
> work towards a common goal. We are all on the same team here, we just
> want to work together. However, if we can't agree on the issue of making
> CSD mandatory for all clients, we'd rather take that then have this
> protocol unmerged.

It's not absolutely mandatory for clients to render decorations, it's
just that anyone running mpv on a compositor which doesn't implement
an optional extension, won't get decorations on it. Personally I don't
think that makes for a good or useful client, but there we go.

Conversely, merging the protocol into wayland-protocols doesn't mean
that every compositor is newly required to implement server-side
decorations. After all, presentation-time and viewport have been
stable for years, and so far no-one else has implemented them, despite
specifically making it possible to have better media playback.

>> > In fact, I have done so. Before we started working on this protocol,
>> > Sway did exactly this. We have provided users the means of overriding
>> > the approach to decorations, including what ends up being double
>> > decorations sometimes.
>>
>> OK, but that doesn't seem like the kind of user experience to aim for ... ?
>
> Yeah, it's not ideal. The impetus for this protocol is to solve this
> problem by getting software written by both camps to negotiate. It's
> clear we're not going to get either side to agree to buy into the other,
> so in the interests of the user we're trying to accomodate both.

I understand that, and the compromise is good. But my view here is
that compositors sticking server-side decorations on unwilling clients
are the ones upsetting the status quo. Your view seems to be that
there _is_ no status quo, so either approach is equally valid in the
absence of explicit negotiation.

>> No, it really has. GTK+ has always - well, until you got the patches
>> for this protocol merged a month or two ago - decorated its own
>> windows under Wayland. Same with Qt. Same with EFL. These are toolkits
>> which have been around and deployed for several years, doing exactly
>> what I'm describing. Sticking server-side decorations on them gives
>> you two completely different titlebars, and anyone trying to use it
>> justifiably thinking the result is an incoherent mess.
>
> Qt (with KDE's help) was the first toolkit to support server side
> decorations - Sway adopted this protocol and sent a patch to GTK+ for
> it. This is a couple of years in the works. Qt has had
> QT_WAYLAND_DISABLE_WINDOWDECORATION for ages.

I don't really feel like an environment variable makes for status quo.

>> It is a concrete, unarguable, fact that the core Wayland protocol
>> implies client-side decorations. The protocol text in this thread
>> acknowledges that fact:
>
> This isn't true. The core Wayland protocol takes no stance at all on any
> kind of decorations. It's designed to accommodate for systems where CSD
> doesn't even make sense, like IVI systems or phones.

Yes, but I think this reinforces my point. If an IVI, phone or
set-top-box compositor suddenly started sticking decorations on the
surfaces it found, it wouldn't be useful. Saying 'but the clients
never asked _not_ to be decorated' wouldn't really help you get out of
it either.

> I don't want to drag this on much further, what changes do we need to
> make to get this merged?

I don't think prolonging the argument is helpful. Just a fairly clear
statement that in the absence of this extension and unless told
otherwise, clients which can decorate themselves, should decorate
themselves, would work for me. I don't want to be painted into a
corner where clients _can_ decorate themselves, but do not because the
compositor does not 

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

[Markus Ongyerth]

On 2018/3月/18 10:50, Eike Hein wrote:
> 
> 
> On 03/16/2018 12:43 AM, Daniel Stone wrote:> No, it really has. GTK+ has
> always - well, until you got the patches
> > for this protocol merged a month or two ago - decorated its own
> > windows under Wayland. Same with Qt. Same with EFL. These are toolkits
> > which have been around and deployed for several years, doing exactly
> > what I'm describing. Sticking server-side decorations on them gives
> > you two completely different titlebars, and anyone trying to use it
> > justifiably thinking the result is an incoherent mess.
> 
> There's also millions of Wayland-based products in the market in which
> Wayland clients do not render decorations, e.g. in TVs and IVI systems.
> Grated, not many of them use much or any of the xdg-* protocols.
> 
> Still, compositors do not reject clients which don't render decorations.
> The core protocol as-yet doesn't make an attempt to define what a
> decoration is, or needs to have in it, on the basis of which it could do
> so, either. If it did, the above Wayland systems would suddenly be in
> violation. I think we agree these Wayland systems are actually fine and
> nice to have.
> 
> I'm personally fine with assuming that many or even all of the initial
> Wayland contributors assumed CSDs on desktop systems. But I think this
> debate over the historic record is obscuring the real needs of this
> review, which should be about making sure the protocol under review is
> durable, flexible and future-proof, and doesn't introduce unintended
> side-effects.
> 
> So here's the problem I see: This protocol introduces a definition of
> what a decoration is and can do (move, resize, change state). A server
> advertising is commits to supporting both, but when a client asks for
> SSDs, the server can respond with "use CSDs"
> 
> So we have two aspects to this:
> 
> a) People are concerned a protocol like this could open the floodgates
> to clients which don't implement CSDs at all and indiscriminately ask
> servers for SSDs whenever they can.
> 
> b) Yet this protocol also allows servers to force clients which prefer
> SSDs to force them into CSD mode, and in fact holds them to implementing
> CSDs with a number of features (which don't make sense in every system).
> 
> In my eyes (b) is pretty clearly more prohibitively costly.
This is an optional protocol that builds upon xdg-shell.
Which, as you said, should not be present on most of these devices.

If a client never wants any decoration, it can just not implement this.
Which should be enough for all Smart-TV apps and the like.

The only problematic case would be applications intended for a normal desktop 
workflow that ask for decor if possible, but never want to draw their own.

> 
> Servers which want to indiscriminately force all clients to provide CSDs
> can just not advertize this interface, which is essentially about
> letting clients know they have a preferred deco to show.
> 
> If they do advertise it, they should allow the client to express a
> preference, not abuse the spirit of the protocol - essentially to
> properly enable compositors which aim to establish a particular workflow
> via decorations (as many existing Wayland compositors do!) - to override
> it. Clients which stubbornly refuse to implement CSDs (e.g. mpv) are
> unlikely to keep up their end of the bargain anyway, but I think it's
> dangerous to run with such a vague definition of "decoration" with
> far-reaching implications.
> 
> S. Ser said "the CSD mode allows the client to do not draw decorations
> at all" in the discussion of v1, but the protocol text certainly doesn't
> agree here by defining what a deco is and requiring clients to support
> one. I agree with M. Blumenkrantz that the 'mode' thing seems wrong as
> it is now. I think the way to go would be:
> 
> a) Change the definition of "decoration" to "window controls as deemed
> appropriate by the compositor, for example ...". This leaves what's in a
> server-side deco and what's in a client-side deco up to servers and
> clients, respectively, and allows this protocol to serve more systems.
While a bit of rewording here (probably to the ambigous state it's in 
xdg-shell) wouldn't hurt, this particular sentence would make CSD very weird, 
since the client doesn't know what the compositor deems appropriate.
I think we should avoid the situation where clients try to guess their env, 
not promote it even further.

> 
> b) Make the protocol about negotiating between "please deco me as you
> see fit" and "I prefer to keep doing my own thing" (which can then still
> be "nothing") cases. I don't think any more is needed. I think client
> devs are smart enough to understand making this requests implies they
> should stop drawing their own title bars, and in the latter case they're
> smart enough to know how exactly they want to decorate their window, as
> e.g. the GTK+ designers clearly are, and this protocol shouldn't
> interfere with them. Certainly the 

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

[Eike Hein]

On 03/16/2018 12:43 AM, Daniel Stone wrote:> No, it really has. GTK+ has
always - well, until you got the patches
> for this protocol merged a month or two ago - decorated its own
> windows under Wayland. Same with Qt. Same with EFL. These are toolkits
> which have been around and deployed for several years, doing exactly
> what I'm describing. Sticking server-side decorations on them gives
> you two completely different titlebars, and anyone trying to use it
> justifiably thinking the result is an incoherent mess.

There's also millions of Wayland-based products in the market in which
Wayland clients do not render decorations, e.g. in TVs and IVI systems.
Grated, not many of them use much or any of the xdg-* protocols.

Still, compositors do not reject clients which don't render decorations.
The core protocol as-yet doesn't make an attempt to define what a
decoration is, or needs to have in it, on the basis of which it could do
so, either. If it did, the above Wayland systems would suddenly be in
violation. I think we agree these Wayland systems are actually fine and
nice to have.

I'm personally fine with assuming that many or even all of the initial
Wayland contributors assumed CSDs on desktop systems. But I think this
debate over the historic record is obscuring the real needs of this
review, which should be about making sure the protocol under review is
durable, flexible and future-proof, and doesn't introduce unintended
side-effects.

So here's the problem I see: This protocol introduces a definition of
what a decoration is and can do (move, resize, change state). A server
advertising is commits to supporting both, but when a client asks for
SSDs, the server can respond with "use CSDs"

So we have two aspects to this:

a) People are concerned a protocol like this could open the floodgates
to clients which don't implement CSDs at all and indiscriminately ask
servers for SSDs whenever they can.

b) Yet this protocol also allows servers to force clients which prefer
SSDs to force them into CSD mode, and in fact holds them to implementing
CSDs with a number of features (which don't make sense in every system).

In my eyes (b) is pretty clearly more prohibitively costly.

Servers which want to indiscriminately force all clients to provide CSDs
can just not advertize this interface, which is essentially about
letting clients know they have a preferred deco to show.

If they do advertise it, they should allow the client to express a
preference, not abuse the spirit of the protocol - essentially to
properly enable compositors which aim to establish a particular workflow
via decorations (as many existing Wayland compositors do!) - to override
it. Clients which stubbornly refuse to implement CSDs (e.g. mpv) are
unlikely to keep up their end of the bargain anyway, but I think it's
dangerous to run with such a vague definition of "decoration" with
far-reaching implications.

S. Ser said "the CSD mode allows the client to do not draw decorations
at all" in the discussion of v1, but the protocol text certainly doesn't
agree here by defining what a deco is and requiring clients to support
one. I agree with M. Blumenkrantz that the 'mode' thing seems wrong as
it is now. I think the way to go would be:

a) Change the definition of "decoration" to "window controls as deemed
appropriate by the compositor, for example ...". This leaves what's in a
server-side deco and what's in a client-side deco up to servers and
clients, respectively, and allows this protocol to serve more systems.

b) Make the protocol about negotiating between "please deco me as you
see fit" and "I prefer to keep doing my own thing" (which can then still
be "nothing") cases. I don't think any more is needed. I think client
devs are smart enough to understand making this requests implies they
should stop drawing their own title bars, and in the latter case they're
smart enough to know how exactly they want to decorate their window, as
e.g. the GTK+ designers clearly are, and this protocol shouldn't
interfere with them. Certainly the protocol hasn't before felt the need
to teach anybody how to do decorations.

Remember: This isn't about "CSD vs. SSD - which is better?!", it's about
making this one protocol hygienic and good.


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

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

[Pekka Paalanen]

On Wed, 14 Mar 2018 06:41:53 -0400
Simon Ser  wrote:

> On March 14, 2018 10:22 AM, Peter Hutterer  wrote:
> > sorry about the delay, but better late than too late ;)  
> 
> No problem, thanks for your review!
> 
> > On Sun, Mar 11, 2018 at 05:53:42PM -0400, 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 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 v2 to v3: fix typos, clarify xdg_toplevel_decoration.destroy
> > > semantics, clarify that clients always need to support CSD and can receive
> > > configure events at any time.
> > > 
> > > [1] https://github.com/swaywm/wlroots/pull/638
> > > 
> > >  Makefile.am|   1 +
> > >  unstable/xdg-toplevel-decoration/README|   4 +
> > >  .../xdg-toplevel-decoration-unstable-v1.xml| 132 
> > > +
> > >  3 files changed, 137 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..a34cb73
> > > --- /dev/null
> > > +++ 
> > > b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
> > > @@ -0,0 +1,132 @@
> > > +
> > > +
> > > +  
> > > +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 

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

[Drew DeVault]

> I understand you dislike Wayland's established window-management model
> and you wish it was the same as X11. I disagree, but that's fine.
> What's not fine, is trying to rewrite history and insulting everyone's
> intelligence. You're acting as if the consensus which has underpinned
> everything since the start of the project doesn't exist, just because
> a) you don't like it, and b) mpv doesn't have decorations so it
> invalidates everything else.

I apologise for insulting your intelligence, it was not my goal. This is
a difficult subject to have productive discourse on, because it's been a
subject of debate for a very long time and we hold very different
opinions. Our goal is to find a compromise, and this protocol is an
attempt to do that.

> Denying facts and being disingenuous doesn't help anyone, and it's
> tiring. Tiring enough that I came into this thread with the intention
> of giving this protocol a couple of suggestions and a push towards
> getting it merged, because I'm tired of the totally counterproductive
> division between wlc/wlroots/Sway/mpv and the rest of the Wayland
> world, but I've lost all motivation to continue.

This is not something wlc/wlroots/sway/mpv is pushing for alone. This
thread represents the opinions of several major players in the Wayland
ecosystem: Sway, KDE, Mir, Way Cooler, waymonad, and bspwc are all
represented here. Given this, it's difficult for me to accept that a
consensus has been reached.

It is my intention to earnestly express the opinion of our projects and
work towards a common goal. We are all on the same team here, we just
want to work together. However, if we can't agree on the issue of making
CSD mandatory for all clients, we'd rather take that then have this
protocol unmerged.

> > In fact, I have done so. Before we started working on this protocol,
> > Sway did exactly this. We have provided users the means of overriding
> > the approach to decorations, including what ends up being double
> > decorations sometimes.
> 
> OK, but that doesn't seem like the kind of user experience to aim for ... ?

Yeah, it's not ideal. The impetus for this protocol is to solve this
problem by getting software written by both camps to negotiate. It's
clear we're not going to get either side to agree to buy into the other,
so in the interests of the user we're trying to accomodate both.

> No, it really has. GTK+ has always - well, until you got the patches
> for this protocol merged a month or two ago - decorated its own
> windows under Wayland. Same with Qt. Same with EFL. These are toolkits
> which have been around and deployed for several years, doing exactly
> what I'm describing. Sticking server-side decorations on them gives
> you two completely different titlebars, and anyone trying to use it
> justifiably thinking the result is an incoherent mess.

Qt (with KDE's help) was the first toolkit to support server side
decorations - Sway adopted this protocol and sent a patch to GTK+ for
it. This is a couple of years in the works. Qt has had
QT_WAYLAND_DISABLE_WINDOWDECORATION for ages.

> Xwayland isn't a shell. Xwayland requires active co-operation from the
> compositor to act just like an X11 window manager, so X11 clients can
> display in the shell being used. X11 has very well-established means
> of doing window management via the ICCCM and EWMH, and the
> implementations I've seen try to respect those as closely as they can.

All of the shells (including xdg-shell) require active co-operation from
the compositor to display correcty.

> It is a concrete, unarguable, fact that the core Wayland protocol
> implies client-side decorations. The protocol text in this thread
> acknowledges that fact:

This isn't true. The core Wayland protocol takes no stance at all on any
kind of decorations. It's designed to accommodate for systems where CSD
doesn't even make sense, like IVI systems or phones.

I don't want to drag this on much further, what changes do we need to
make to get this merged?

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

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

[Daniel Stone]

On 15 March 2018 at 15:21, Drew DeVault  wrote:
> On 2018-03-15  3:16 PM, Daniel Stone wrote:
>> You could write a compositor which put decorations on everything
>> unless explicitly instructed not to, and claim victory in the name of
>> technical correctness. Even though it's double-decorating GTK+, EFL,
>> Weston, and pretty much everything deployed under the sun.
>
> In fact, I have done so. Before we started working on this protocol,
> Sway did exactly this. We have provided users the means of overriding
> the approach to decorations, including what ends up being double
> decorations sometimes.

OK, but that doesn't seem like the kind of user experience to aim for ... ?

'You might have no titlebars and controls, or one of them, or maybe
two completely different ones, depending on historical decisions made
by developers who weren't talking to each other at the time. Have
fun.'

>> We already have a specification, which is what every client expects:
>> that clients are responsible for the decorations (or absence thereof).
>> We now have a new protocol which allows the client and server, when
>> both agree, to have the server take responsibility for drawing (or not
>> drawing) the decorations. And that's fine, but why try to retcon
>> history as if the past several years never existed, just because you
>> disagree with it?
>
> I don't think I'm being overtly "technically strict" in my
> interpretation of the standard. This assumption hasn't really been true.
> Take Xwayland, for example, a shell where the compositor has always been
> expected to handle decorations.

Xwayland isn't a shell. Xwayland requires active co-operation from the
compositor to act just like an X11 window manager, so X11 clients can
display in the shell being used. X11 has very well-established means
of doing window management via the ICCCM and EWMH, and the
implementations I've seen try to respect those as closely as they can.

> There are also other clients in the wild which are not amenable to
> client side decorations. mpv comes to mind, there was a big debate over
> it and to date it still doesn't support CSD (it uses xdg-shell).

Yes, so mpv gets no decorations unless it asks the server for them.
Neither does weston-simple-egl. There are several compositors which
will never provide decorations for mpv, because they don't support
server-side decorations. And that's OK, because that's the established
ecosystem: clients provide decorations.

> The "requirement" has never been as strong as you're implying, and
> certainly has never been expressed in the protocols.

No, it really has. GTK+ has always - well, until you got the patches
for this protocol merged a month or two ago - decorated its own
windows under Wayland. Same with Qt. Same with EFL. These are toolkits
which have been around and deployed for several years, doing exactly
what I'm describing. Sticking server-side decorations on them gives
you two completely different titlebars, and anyone trying to use it
justifiably thinking the result is an incoherent mess.

I understand you dislike Wayland's established window-management model
and you wish it was the same as X11. I disagree, but that's fine.
What's not fine, is trying to rewrite history and insulting everyone's
intelligence. You're acting as if the consensus which has underpinned
everything since the start of the project doesn't exist, just because
a) you don't like it, and b) mpv doesn't have decorations so it
invalidates everything else.

It is a concrete, unarguable, fact that the core Wayland protocol
implies client-side decorations. The protocol text in this thread
acknowledges that fact:
By advertizing this interface the server anounces support for
server-side window decorations.

Denying facts and being disingenuous doesn't help anyone, and it's
tiring. Tiring enough that I came into this thread with the intention
of giving this protocol a couple of suggestions and a push towards
getting it merged, because I'm tired of the totally counterproductive
division between wlc/wlroots/Sway/mpv and the rest of the Wayland
world, but I've lost all motivation to continue.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Drew DeVault]

On 2018-03-15  3:16 PM, Daniel Stone wrote:
> You could write a compositor which put decorations on everything
> unless explicitly instructed not to, and claim victory in the name of
> technical correctness. Even though it's double-decorating GTK+, EFL,
> Weston, and pretty much everything deployed under the sun.

In fact, I have done so. Before we started working on this protocol,
Sway did exactly this. We have provided users the means of overriding
the approach to decorations, including what ends up being double
decorations sometimes.

> We already have a specification, which is what every client expects:
> that clients are responsible for the decorations (or absence thereof).
> We now have a new protocol which allows the client and server, when
> both agree, to have the server take responsibility for drawing (or not
> drawing) the decorations. And that's fine, but why try to retcon
> history as if the past several years never existed, just because you
> disagree with it?

I don't think I'm being overtly "technically strict" in my
interpretation of the standard. This assumption hasn't really been true.
Take Xwayland, for example, a shell where the compositor has always been
expected to handle decorations.

There are also other clients in the wild which are not amenable to
client side decorations. mpv comes to mind, there was a big debate over
it and to date it still doesn't support CSD (it uses xdg-shell).

The "requirement" has never been as strong as you're implying, and
certainly has never been expressed in the protocols.

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

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

[Daniel Stone]

Hi,

On 15 March 2018 at 15:12, Drew DeVault  wrote:
> On 2018-03-15  3:04 PM, Mike Blumenkrantz wrote:
>> It seems to me that there is no harm in restating that clients are required
>> to implement CSD inside a protocol which permits adding a separate,
>> optional method of window decoration.
>>
>> Note that it is not an assumption that clients/compositors "support both"
>> modes, it's a hard requirement that clients/compositors support CSD. If
>> there is some confusion about this due to other protocols not explicitly
>> stating that CSD is required then this can easily be remedied by adding
>> such clauses.
>
> Sorry for the confusion. My point is that Wayland does not and has never
> required clients to show client side decorations.

In the most strict technical terms, you're right.

> The only connection is
> a rather loose one specified in xdg-shell. In practice, clients and
> compositors alike are free to do whatever they want with decorations.

You could write a compositor which put decorations on everything
unless explicitly instructed not to, and claim victory in the name of
technical correctness. Even though it's double-decorating GTK+, EFL,
Weston, and pretty much everything deployed under the sun.

> We
> should not formalize a requirement to behave any particular way. This
> just provides a means of communicating each side's preferences.

We already have a specification, which is what every client expects:
that clients are responsible for the decorations (or absence thereof).
We now have a new protocol which allows the client and server, when
both agree, to have the server take responsibility for drawing (or not
drawing) the decorations. And that's fine, but why try to retcon
history as if the past several years never existed, just because you
disagree with it?

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

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

[Drew DeVault]

On 2018-03-15  3:04 PM, Mike Blumenkrantz wrote:
> It seems to me that there is no harm in restating that clients are required
> to implement CSD inside a protocol which permits adding a separate,
> optional method of window decoration.
> 
> Note that it is not an assumption that clients/compositors "support both"
> modes, it's a hard requirement that clients/compositors support CSD. If
> there is some confusion about this due to other protocols not explicitly
> stating that CSD is required then this can easily be remedied by adding
> such clauses.

Sorry for the confusion. My point is that Wayland does not and has never
required clients to show client side decorations. The only connection is
a rather loose one specified in xdg-shell. In practice, clients and
compositors alike are free to do whatever they want with decorations. We
should not formalize a requirement to behave any particular way. This
just provides a means of communicating each side's preferences.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Mike Blumenkrantz]

It seems to me that there is no harm in restating that clients are required
to implement CSD inside a protocol which permits adding a separate,
optional method of window decoration.

Note that it is not an assumption that clients/compositors "support both"
modes, it's a hard requirement that clients/compositors support CSD. If
there is some confusion about this due to other protocols not explicitly
stating that CSD is required then this can easily be remedied by adding
such clauses.

On Wed, Mar 14, 2018 at 3:20 PM Drew DeVault  wrote:

> On 2018-03-14  3:16 PM, Simon Ser wrote:
> > However, the situation we'd like to avoid is clients wanting decorations
> not
> > implementing CSD at all and relying on this protocol to show them via
> SSD. What
> > about rewording this sentence to:
>
> I understand where you're coming from, but this is not something to be
> avoided, rather it should be embraced.
> ___
> 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 v3] unstable: add xdg-toplevel-decoration protocol

[Drew DeVault]

On 2018-03-14  3:16 PM, Simon Ser wrote:
> However, the situation we'd like to avoid is clients wanting decorations not
> implementing CSD at all and relying on this protocol to show them via SSD. 
> What
> about rewording this sentence to:

I understand where you're coming from, but this is not something to be
avoided, rather it should be embraced.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Simon Ser]

On March 14, 2018 7:33 PM, Drew DeVault  wrote:
> On 2018-03-14  6:41 AM, Simon Ser wrote:
> > > Since we assume CSD by default, this implies that any client must be able 
> > > to
> > > do CSD, which should be explicitly stated here.
> > 
> > It's already stated in the protocol description ("Note that even if
> > the server supports server-side window decorations, clients must still
> > support client-side decorations"). Is it necessary to write it one
> > more time here?
> 
> I don't think this is right. The protocol has nothing to say at all
> about decorations, client side or not. A Wayland surface without CSD is
> a valid Wayland surface on any compositor. I don't think we need to
> explicitly require clients to handle CSD for that reason.

You're right, xdg-shell does mention client-side decorations, but never makes
them mandatory. Clients not having decorations can use xdg-toplevel.

However, the situation we'd like to avoid is clients wanting decorations not
implementing CSD at all and relying on this protocol to show them via SSD. What
about rewording this sentence to:

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

> The assumption is that the compositor implementing this protocol will
> support both.
> 
> --
> Drew DeVault

---
Simon Ser
https://emersion.fr​

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

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

[Drew DeVault]

On 2018-03-14  6:41 AM, Simon Ser wrote:
> > Since we assume CSD by default, this implies that any client must be able to
> > do CSD, which should be explicitly stated here.
> 
> It's already stated in the protocol description ("Note that even if
> the server supports server-side window decorations, clients must still
> support client-side decorations"). Is it necessary to write it one
> more time here?

I don't think this is right. The protocol has nothing to say at all
about decorations, client side or not. A Wayland surface without CSD is
a valid Wayland surface on any compositor. I don't think we need to
explicitly require clients to handle CSD for that reason.

The assumption is that the compositor implementing this protocol will
support both.

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

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

[Simon Ser]

On March 14, 2018 10:22 AM, Peter Hutterer  wrote:
> sorry about the delay, but better late than too late ;)

No problem, thanks for your review!

> On Sun, Mar 11, 2018 at 05:53:42PM -0400, 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 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 v2 to v3: fix typos, clarify xdg_toplevel_decoration.destroy
> > semantics, clarify that clients always need to support CSD and can receive
> > configure events at any time.
> > 
> > [1] https://github.com/swaywm/wlroots/pull/638
> > 
> >  Makefile.am|   1 +
> >  unstable/xdg-toplevel-decoration/README|   4 +
> >  .../xdg-toplevel-decoration-unstable-v1.xml| 132 
> > +
> >  3 files changed, 137 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..a34cb73
> > --- /dev/null
> > +++ 
> > b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
> > @@ -0,0 +1,132 @@
> > +
> > +
> > +  
> > +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 

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

[Peter Hutterer]

sorry about the delay, but better late than too late ;)

On Sun, Mar 11, 2018 at 05:53:42PM -0400, 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 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 v2 to v3: fix typos, clarify xdg_toplevel_decoration.destroy
> semantics, clarify that clients always need to support CSD and can receive
> configure events at any time.
> 
> [1] https://github.com/swaywm/wlroots/pull/638
> 
>  Makefile.am|   1 +
>  unstable/xdg-toplevel-decoration/README|   4 +
>  .../xdg-toplevel-decoration-unstable-v1.xml| 132 
> +
>  3 files changed, 137 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..a34cb73
> --- /dev/null
> +++ b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
> @@ -0,0 +1,132 @@
> +
> +
> +  
> +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 advertising this interface the server 

[PATCH wayland-protcols v3] 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 v2 to v3: fix typos, clarify xdg_toplevel_decoration.destroy
semantics, clarify that clients always need to support CSD and can receive
configure events at any time.

[1] https://github.com/swaywm/wlroots/pull/638

 Makefile.am|   1 +
 unstable/xdg-toplevel-decoration/README|   4 +
 .../xdg-toplevel-decoration-unstable-v1.xml| 132 +
 3 files changed, 137 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..a34cb73
--- /dev/null
+++ b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
@@ -0,0 +1,132 @@
+
+
+  
+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 advertising this interface the server announces support for 
server-side
+  window decorations. Note that even if the server supports server-side
+  window decorations, clients must still support client-side decorations.
+
+  Warning! The protocol described in this file is experimental and
+  backward incompatible changes may be made. Backward compatible changes
+  may be