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.

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

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

Drew DeVault
wayland-devel mailing list

Reply via email to