On Wed, Apr 28, 2021 at 10:27 AM Vlad Zahorodnii <vlad.zahorod...@kde.org> wrote: > > On 3/23/21 6:27 PM, Aleix Pol wrote: > > I don't feel like there's a use-case for it. > > > > I also don't have the feeling that having 2 separate repositories help > > with anything. Moving code from one side to another is cumbersome and > > makes history tracking more complex. > > > > I think it would be even cool if we didn't have kwayland-server > > altogether. From my perspective, its only reason to be is > > kscreenlocker which needs some classes from it: > > KWayland::Server::Display and KWayland::Server::ClientConnection. > > That's a fair argument. My main gripe with the current architecture is > that the split between kwayland-server and kwin makes it more difficult > to implement some protocols. > > For example, client buffers can't be implemented entirely inside > kwayland-server because at some point we need to ask the renderer to > provide us a texture or additional info about the buffer. At the moment, > we work around that by adding EGLDisplay info to the Display so we can > call eglQueryWaylandBuffer in BufferInterface or taking an additional > Impl object as in LinuxDmabufUnstableV1Interface. > > I think that the wayland machinery and the rest of the compositor > (backends, renderer, etc) need to live in the same repo, either > kwayland-server or kwin. > > I do agree that things will be better off without a separate repo for > wayland wrappers. I guess if the need for a library to write compositors > arises, we can just refactor libkwin and make it more general purpose. > > My question is: why does kscreenlocker need KWayland::Server::Display? > Can we port it to QLocalServer/QLocalSocket?
When I moved KWayland Server I took the kscreenlocker dependency for granted, it's something I didn't question. I can't say I understand why it needs to have a wayland server there. +1 for unifying them and refactoring all within a product. It must stay properly separate but it would allow us to organise the components in ways that make sense beyond the frameworks splitting much like you are finding right now. Aleix
