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

[Jonas Ådahl]

On Tue, Apr 17, 2018 at 05:37:48PM -0400, Simon Ser wrote:
> (Re-sending the message because I forgot to reply to the list)
> 
> On April 13, 2018 2:56 PM, Jonas Ådahl <jadahl at gmail.com> wrote:
> > Another thing to consider is whether non-toplevels ever want a similar
> > kind of protocol? It is not something we need to go into much further
> > details now, but it would be easy to add into this protocol by just
> > renaming the directory under unstable/ and the XML file to
> > "xdg-decorations" or something. Would we have another type of surface
> > that needs similar functionality, we could add that as a separate pair
> > of interfaces.
> 
> 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.

> 
> > Is this the consensus as well? Because if it should be possible, there
> > are those things I mentioned to consider regarding capabilities. A
> > potential mode could for example be to outsource drawing shadow or
> > something.
> 
> As Drew, I think the complexity isn't worth it. Compositors wanting to draw
> shadows around clients will get into more issues (e.g. getting the shape of the
> window).
> 
> > Ignoring that for a bit, I guess the reason for allowing the compositor
> > to disregard the set mode to be that a client might not know whether
> > request ssd or csd? Especially in the example you gave above. Then what
> > is the purpose of the set_mode request at all?
> 
> The set_mode request allows the client to communicate its preference, but still
> allow the compositor to override it. For instance, a GTK+ client with a titlebar
> containing widgets might prefer CSD, but could still accept to use SSD by
> turning the titlebar into a toolbar.

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.

> 
> That would work well in tiling compositors when moving a window between a tiled
> container and a floating container: the compositor could accept the set_mode
> request in floating mode and enforce SSD in tiled mode. We could imagine another
> compositor letting clients decorate themselves if they want to in tiled mode,
> in which case the compositor would send preferred_mode events when switching
> between tiled and floating containers.

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?

For example, I imagine this could happen otherwise:

Cmp: -> preferred mode(B)
Cli: -> set_mode(B)
Cmp: -> configure(B)
Cli: -> draw+commit assuming B
*draw as B* (wanted)
Cmp: -> preferred mode(A)
Cmp: -> configure(B)
Cli: -> set_mode(A)
Cli: -> draw+commit assuming B
*draw as B* (temporary unwanted state)
Cmp: -> configure(A)
Cli: -> draw+commit assuming A
*draw as A* (wanted)
 
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.


Jonas