[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