[PATCH wayland-protocols v4] unstable: add xdg-toplevel-decoration protocol

[Simon Ser]

On April 18, 2018 10:28 AM, Jonas Ådahl <jadahl at gmail.com> wrote:
> > I'm not sure it's a good idea to add decorations to non-toplevel surfaces. I
> > can't think of a use-case for popups. We don't know yet what kind of
> > xdg-surface will be added later, so I think we can't really design a protocol
> > that would work for this unknown use-case and we'd better create a new protocol
> > instead.
> 
> That's not what I suggested. I just suggested to make room for potential
> future xdg_surface based surface types by renaming a directory and a
> file. We should indeed not bother with adding any more complexity to
> popups and not-yet-thought-of surface types.

Oh, sorry, I thought you wanted to allow clients to create xdg-decoration
objects for arbitrary xdg-surfaces. What you said makes much more sense now: it
will just allow to add new interfaces to the protocol for future xdg-surfaces.
Yeah, I'm definitely on board with that.

> While I don't think it makes sense to do this in GTK+ (we can't just
> mess around with applications widget trees however we want) but I can
> accept that it may be a theoretical possibility for a theoretical
> toolkit.

You could also decide to style the titlebar differently, for instance hiding
the window title and reducing padding. But of course all of this is up to the
client.

> How do you imagine avoiding state transitions that don't result in
> incorrect intermediate state? If a compositor changes the preferred
> mode, does it wait some arbitrary time to see if client replies with a
> new set_mode request? Or how else would one avoid sending a new
> configuration given the changed tiled-ness without knowing what the
> client prefers?

I don't think "wait[ing] some arbitrary time" is an acceptable behaviour.
Instead, I think the compositor has two choices:

- Either it decides to respect the client's choice (because it allows both
  CSD and SSD in this situation), in which case it just sends preferred_mode and
  lets the client send (or do not send) a set_mode request.
- Either it decides to enforce a particular mode (because it only allows for one
  mode in this situation), in which case it just sends configure.

This "I want to know the client's preferred mode before I decide if I force one
mode or let the client choose" behaviour is a little weird.

> Wouldn't it be better to have actual clients that'd actually use this
> part of the protocol before writing it down? We could still move forward
> with a vastly simpler protocol without the set_mode and set_preferred,
> and just have the mode enum and configure (so that the compositor can
> switch between csd and ssd when tiling/untiling or whatever) that works
> with the all available clients we have today.

We could always do this and add preferred_mode & set_mode later. Note that the
current test client uses this part of the protocol (it can be configured to use
the compositor's preferred mode or use its own preferred mode), but it's just a
test client.