Problems in KWayland causes by API and ABI compatibility promises

[Aleix Pol]

On Mon, Mar 23, 2020 at 3:45 PM David Edmundson
<david at davidedmundson.co.uk> wrote:
>
> >
> > 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

We can decide what we want for KF6 and act accordingly. If for
example, we were to split kwayland into kwaylandclient and
kwaylandserver and the latter be in plasma, we could consider putting
new code in KWin or a shared repository.

In fact, if we ever want to have such a kwayland server and are
serious about it, we'll want to be mindful about what we put there.
Much like any other framework, we only put things on the framework
when it's going to be shared rather than putting some parts of the
code somewhere by policy like we've been doing here.

Aleix