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

[Jonas Ådahl]

On Fri, Apr 13, 2018 at 10:03:11AM -0400, Drew DeVault wrote:
> On 2018-04-13  3:56 PM, Jonas Ådahl wrote:
> > What is the purpose of making the compositor changing the "preferred"
> > mode? If we would make the assumption that a compositor stays the same
> > during the whole session as in it'll either always prefer or not prefer
> > dealing with decorations, and we assume that we always only have the two
> > "modes", the protocol could probably be greatly simplified by just
> > having a destroy function, and assuming a client having created the
> > decoration object always outsourcing the drawing decorations etc to the
> > compositor.
> 
> It may change during the session. User might change their config files
> and reload, for example. A toplevel might be changed from a tiling
> layout to a floating one and the compositor might prefer floating
> toplevel decorate themselves, for example.

That's a good point.

> 
> > If we add more modes, compositor or clients are forced to support all
> > different combinations of modes to support new versions of the protocol.
> 
> I don't foresee new modes being added.

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.

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?

Lets assume a client that have the ability to outsource window
decoration rendering, creates the decoration object; great, the
compositor will, based on its own preference and knowledge about the
window at configure time whether it wants to tile, decorate etc and
configures the surface accordingly. No need for the set_mode() request,
nor the preferred_mode event.

Client that doesn't have that ability (e.g. gedit, nautilus, chromiuim
etc) will simply not create the decoration object because the window
decoration is part of the main user interface. No need for the
set_mode() request, nor the preferred_mode event.

What other scenarios are there?

> 
> > 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 think that for the time being it would be wise to proceed under the
> assumption that we won't have another shell that needs this. I would
> sooner advocate for the continued development of xdg-shell than for a
> new shell with desktop-like capabilities.
> 
> This might turn out to be short-sighted but a new shell would probably
> break enough other stuff that this'll just be another pill of many we
> have to swallow when the time comes.

I'm not really talking about a new shell, but about e.g xdg_popup, or if
we for some reason need another xdg_surface based window type that is
neither xdg_popup or xdg_toplevel.


Jonas

> 
> --
> Drew DeVault