On 3/24/20 4:35 PM, Aleix Pol wrote:
We can decide what we want for KF6 and act accordingly. If for
example, we were to split kwayland into kwaylandclient and
kwaylandserver and the latter be in plasma, we could consider putting
new code in KWin or a shared repository.

I was also thinking about splitting KWayland into KWaylandClient and KWaylandServer. However, later on, I realized that this is a bad idea because it'll make implementing new protocols more difficult and testing wrappers will become more difficult. In fact, I don't think that we'll be able to keep existing tests in the kwayland repo; we will probably have to drop them.

In fact, if we ever want to have such a kwayland server and are
serious about it, we'll want to be mindful about what we put there.
Much like any other framework, we only put things on the framework
when it's going to be shared rather than putting some parts of the
code somewhere by policy like we've been doing here.

The problem is that we can't keep KWayland stable; at least, right now. There are still things in the wild that need a protocol or something and as we implement those protocols, we might need some of existing wrappers to adapt to the new changes or rework them completely. One such example that comes to my mind is the explicit synchronization protocol.

I think it's a good thing to have helper classes for Wayland protocols that you could plug in and get a running compositor, this is a great idea, but I think it's way too early to promise API and ABI guarantees.


Reply via email to