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 firstname.lastname@example.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel