Problems in KWayland causes by API and ABI compatibility promises

[David Edmundson]

On Wed, Apr 8, 2020 at 5:10 PM Kevin Ottens <ervin at 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.