On 2018-05-08 11:23 AM, Jonas Ådahl wrote: > So the purpose here is to provide a way to allow constructing a desktop > environment by combining different components more or less arbitrarily. > I also assume this is a newer version of the one proposed > earlier[0][1][2].
Aye. > 1) The protocols distributed should be seen as functionality a client > can potentially expect from any compositor. I disagree. I think that the scope should be functionality several compositors and/or clients implement. wayland.xml is for functionality a client can expect from any compositor. > 2) Things for constructing and/or configuring a desktop environment will > often need to be privileged, which is not something we handle currently. > This is a reason we have always avoided anything similar to a > "wl_randr", and I expect panels and similar things have similar > complications and requirements. We are of the opinion that these protocols will not need to change as means of securing them are added. > It is my opinion that we should continue with the scope described above, > to make a clear separation between what portable clients can expect > while expecting to work both on highly integrated environments and less > integrated environments alike. > > With all this being said, this obviously doesn't mean one can not make a > Wayland DE out of a multitude of third party components; wayland (the > repository and tarball) and wayland-protocols are not the only way to > distribute protocols. There is already wayland-wall[3] which aims to > cover the use case for building a desktop environment by combining > different components, and there is no reason why we can't have more > sources (maybe a future test suite for example?). I don't think anyone is interested in wayland-wall. wayland-protocols is a better place for this. wayland-protocols already has many protocols that don't make sense for all compositors: fullscreen-shell doesn't make sense in many compositors, xwayland-keyboard-grab should probably live in the xwayland tree by your arguments, and protocols like pointer-gestures are unlikely to ever see an implementation in my compositor. It's better if wayland-protocols doesn't have the goal of collecting "blessed" protocols that everyone is supposed to implement. The protocol everyone is supposed to implement is wayland.xml. Instead, we should use it to provide a review process for protocols common across the ecosystem. One of the biggest complaints people have about Wayland is the lack of cooperation between compositors. Lots of stuff users rely on breaks during the transition because none of us can agree on how to make these kinds of "desktop extension" clients. Instead of sitting in an ivory tower of design, we are better off by acknowleding our user's needs and making interopable protocols together. That doesn't mean everyone has to play ball, but for those that want to, wayland-protocols shouldn't be in our way. I understand that it would probably be bad to take a bunch of protocols that no one has any stake in, this is why I disagree with wayland-wall. However, layer-shell has the backing of 5 compositor implementations (likely to be 6 soon) and has many client implementations. Is the role of wayland-protocols to be a small few who judge the worthiness of protocols for inclusion, or an instrument of the community? Because the community supports this protocol. -- Drew DeVault _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
