Problems in KWayland causes by API and ABI compatibility promises

[David Edmundson]

>
> That's a good question! On one hand, it's nice to have Qt-friendly
> wrappers for Wayland protocols. On the other hand, it would be even
> better to have a library to write Wayland compositors. So, one just
> needs to plug a few classes in order to get started with drm and
> xdg-shell stuff.

>On the other hand, it would be even better to have a library to write Wayland compositors.

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.

>
> > ----
> >
> > To bootstrap this I've started an initial list of discrete yes/no
> > questions to help serve as a starting point of what kwayland's
> > direction specifically should be.
> >

I agree with you on all your responses to my question set.
Which means landing your implementation of wmbase somewhere makes
sense as it removes that one awkward abstraction.

----

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

It's worth me mentioning that I have made another compositor based on
kwayland, my Qt out of process plasmoids.

>Another option is to move KWayland somewhere else, e.g. KWin or Plasma.

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.

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.

For KF6 we have more options.

David