On Wed, Apr 8, 2020 at 5:10 PM Kevin Ottens <er...@kde.org> wrote: > > Hello, > > On Wednesday, 1 April 2020 14:04:10 CEST David Edmundson wrote: > > Here is a list of active uses of the KWayland::Client API. > > > > frameworks > > plasma-framework (for window positioning) > > > > apps: > > spectacle (for window positioning) > > kdeconnect-kde (for fake input) > > yakuake (for window positioning) > > > > extragear > > latte-dock (for window positioning, custom shadow (which could be > > ported already) and windowmanagement) > > The part of the list above makes me wonder, shouldn't the window positioning > and windowmanager features be on KWindowSystem?
Yeah, doing that will resolve 90% of the client cases. In general for things like blur and everything the slightly higher level abstraction is working out better as we can abstract X and wayland in one go, which really helps the client code. Also, it's worth really clarifying that in absolutely any proposal KWayland as-is can't go away, so clients using that will still function. The slight twist on that which we need to be wary of is that client code will return shared objects if you request a KWaylandClient::PlasmaShellSurface::get(window()) for the same window from two places you'll get the same PlasmaShell instance returned - and therefore the same wl_resource. If we hypothetically had a kwayland2::client also have a plasmashellsurface::get() method we would have two plasma_shellsurface wl_resources's for the same wl_surface which is a protocol error and our client will get violently killed. > > workspace: > > kwin unit tests > > libkscreen > > breeze (till Qt5.15) > > oxyen (till Qt5.15) > > xdg-desktop-portal > > kinfocenter > > plasma-workspace > > plasma-nano > > kscreenlocker > > powerdevil > > kwayland-integration (the backend for kwindowsystem) > > plasma-phone-components > > plasma-integration > > I think the above is less of an issue, right? Because workspace would have a > copy of KWayland which could be shared with whatever stability constraints > needed. It means it has to stay as an exported workspace lib, but yeah it wouldnt' be a problem.