Hello, On Thursday, 16 April 2020 23:38:23 CEST David Edmundson wrote: > On Wed, Apr 8, 2020 at 5:10 PM Kevin Ottens <er...@kde.org> wrote: > > 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.
Sounds like a plan then. > 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. Of course, it's just that the one in KF would become frozen and deprecated until KF6. But then the development would move on with the other copy which would be less of a burden for everyone. > 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. Honestly you lost me here. :-) > > > 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. Yes, exactly my position as well. Regards. -- Kevin Ottens, http://ervin.ipsquad.net enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en
signature.asc
Description: This is a digitally signed message part.
