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
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.