Problems in KWayland causes by API and ABI compatibility promises

[Vlad Zahorodnii]

Hi,

On 3/23/20 4:44 PM, David Edmundson wrote:
> Yeah, I feel that's what kwayland was originally going for. Seat, for
> example, does a lot of dispatching and logic internally.
> Then it drifted into being just wrappers.
> 
> We do need to answer that question definitively otherwise we'll be
> forever stuck coding against each other.

I think that's the direction towards which we should move - a library 
with components that one could plug in to get started with writing a 
Wayland compositor.

> This thread hasn't fully addressed your initial comments on ABI and API.

Yes, my concerns about ABI and API compatibility promises have been 
fully addressed unfortunately.

> Moving is far far from trivial. We have plasma-framework depend on
> kwayland client API. And moving just the server API would break the
> client tests. We also have a released spectacle using kwayland.
> It'll be really messy, plus there's any damage this could do to
> distro's opinion on frameworks as a whole.

Yes, plasma-framework uses KWayland client API for Plasma::Dialog and 
shadows. It is worth to highlight that the shadows integration stuff is 
going to be ported to generic KWindowSystem shadows API in KF 5.70, so 
that's minus one. :-)

> Realistically within KF5 we have two options:
>    - We can start to introduce more versioned classes and see if that
> helps address the problem before we make more drastic policy changes
> 
>    - We can put new protocols somewhere else and elevate them in
> frameworks when they actually have users
> 
> My fear with the latter is that we'll end up over time, we'll start
> forking existing protocols in wayland to fix things and ultimately end
> up in an even messier fragmented state.

Yes, that's what I'm afraid of too. The problem with the former is that 
we can end up with a lot of versioned classes. API-wise this won't cause 
problems for end users, but it'll definitely make things more difficult 
internally, e.g. if we have two implementations of the xdg_wm_base 
protocol, then wrappers for the xdg-decoration or xdg-foreign protocol 
would need to deal with those versioned classes.

Cheers,
Vlad