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

[Jonas Ådahl]

On Fri, Apr 13, 2018 at 10:48:56AM -0400, Drew DeVault wrote:
> 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.

In GTK+ I assume it could be implemented as,

* If there are widgets added to the titlebar, don't create the
  decoration object.

* If none are added, create the decoration object and obey the
  compositors order.

Neither these need the "set_mode" or "preferred_mode" stuff.

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

Not sure what you mean here. The surface is from the client here only,
and the client has no wiggle room in the proposed protocol, only the
compositor.

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

As the protocol is defined here, the only way for these clients to
function is to not bind the global though, as otherwise they might be
force to do something that they cannot.

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

That's something that can be done too. What I meant, however, was to
rename the XML file and the directory which it is in. If new window
types are added etc, their requirements might differ, but making the
"protocol group" slightly more generic sounding, it'd be more flexible
for additions in the future.


Jonas

> 
> --
> Drew DeVault