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

[Drew DeVault]

On 2018-04-13  4:35 PM, Jonas Ådahl wrote:
> 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.

This use-case is valid, but seems thin to me. I don't think it's worth
the additional complexity to implement. Just my personal opinion,
though, I can't speak for others (however, the interested parties are
all copied on this thread).

> 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?

Some clients may choose to respect the wishes of the compositor in some
situations and not in others. GTK+, for example, supports adding UI
elements to its titlebars. My patch for the old protocol only respects
the compositor's decision if the program has not added any interactive
elements to the titlebar.

Clients have an arbitrary surface in which they can render whatever they
want, including decorations. Compositors have an arbitrary surface in
which they can render whatever they want, including decorations. The
protocol acknowledges that after negotiations either party can do
whatever they want, but communicates their choice to each other so they
can make more educated decisions.

> 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.

We've talked about similar approaches to other things in wlroots and, at
least for our group, the consensus is that we don't generally like
changing behaviors simply based on the existence of a resource. We may
as well be explicit.

> 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.

I see, this is a good point. I agree that it would be better to attach
it to the xdg_surface rather than the toplevel, then.

--
Drew DeVault