Re: Problems in KWayland causes by API and ABI compatibility promises
We had a meeting. It resulted in some final action decisions. These will affect the kwayland folder in frameworks. The meeting was attended by: Kevin Ottens, Vlad Zahorodnii, Aleix Pol, Myself, Benjamin Port who all approved the plan. *Protocols:* We make a new repo. It will contain just protocol XML files. plasma-wayland-protocols - target is kdesupport. Existing protocols remain exactly the same, just moved New protocols follow upstream wayland-protocols naming scheme using the "zkde_" prefix *Client - short term:* We leave things unchanged. Kwin tests will continue to use KWayland::Client as is, the upcoming fork KWayalndServer (mentioned in a bit) will stil use it. If something comes up that requires an ABI break or new classes from client (XdgShell for example) we deal with it locally in the relevant repo as per the longer term plan. We slowly migrate to the long term plan. *Client - long term direction:* If something is used in N places - we should abstract things in a high level API like KWindowSystem. If it's used in 1 place, we go native with QtWayalndClientExtension and the generated classes. Autotests for the server should use generated low-level classes, see for example the currently merged tabletmanager autotest. If we need something in kwin and KWaylandServer, we just do it in both. Client will still have a KF6 library for doing super core stuff such as ConnectionThread, wl_surface, buffers etc. It won't contain all the extra protocols. At KF6 we rename namespace and repo to KWaylandClient. *Server - short term:* We make a new repo. It forks existing KWayland::server classes from framework's kwayland + the autotests. This goes into kwaylandserver - put in workspace - no ABI/API guarantees, but released in sync with kwin - .so bumps each time - new namespace (i.e KWaylandServer) - Institute a complete freeze of the server folder in KF5 *Server - long term direction:* - Unit tests migrate to testing against just generated code for the extra protocols - Drop Interface suffix in class names. - Drop from KF6 I'm very hopefully this will really help spur our kwin and wayland efforts as well as prepare us for KF6. Regards David
Re: Problems in KWayland causes by API and ABI compatibility promises
On Thu, Apr 16, 2020 at 10:26 PM David Edmundson wrote: > > > Given Doodle's take forever and everyone's probably quarantined > > anyway, I propose we do it just after the Monday Plasma meeting. If > > someone is eager to share an opinion and can't make that, message here > > and we'll choose something more formally. > > That didn't really work out. Doodle it is! > > https://doodle.com/poll/k8gzdvwhgibn7hma > > Then we'll meet in #kwin on IRC Decision made, lets have an IRC meeting Thursday 17.30 European Time (please adjust for your timezone, or see Doodle). Let's all agree on a decision (though I think there's some direction) by the end of that meeting with some action plans for both client and server both shortterm and long term. David
Re: Problems in KWayland causes by API and ABI compatibility promises
> > 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. > > Honestly you lost me here. :-) Mixing libs for different protocols within one client is ok. Mixing libs for the same protocol within one client is bad. Hopefully the other kwin people will understand what I meant. David
Re: Problems in KWayland causes by API and ABI compatibility promises
Hello, On Thursday, 16 April 2020 23:38:23 CEST David Edmundson wrote: > On Wed, Apr 8, 2020 at 5:10 PM Kevin Ottens wrote: > > 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. Sounds like a plan then. > 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. Of course, it's just that the one in KF would become frozen and deprecated until KF6. But then the development would move on with the other copy which would be less of a burden for everyone. > 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. Honestly you lost me here. :-) > > > 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. Yes, exactly my position as well. Regards. -- Kevin Ottens, http://ervin.ipsquad.net enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en signature.asc Description: This is a digitally signed message part.
Re: Problems in KWayland causes by API and ABI compatibility promises
On Wed, Apr 8, 2020 at 5:10 PM Kevin Ottens 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.
Re: Problems in KWayland causes by API and ABI compatibility promises
> Given Doodle's take forever and everyone's probably quarantined > anyway, I propose we do it just after the Monday Plasma meeting. If > someone is eager to share an opinion and can't make that, message here > and we'll choose something more formally. That didn't really work out. Doodle it is! https://doodle.com/poll/k8gzdvwhgibn7hma Then we'll meet in #kwin on IRC David
Re: Problems in KWayland causes by API and ABI compatibility promises
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? I got no idea regarding kdeconnect-kde and the fake input... > 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. Hope that helps. :-) Regards. -- Kevin Ottens, http://ervin.ipsquad.net enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en signature.asc Description: This is a digitally signed message part.
Re: Problems in KWayland causes by API and ABI compatibility promises
Kevin, thanks for your input. I think there's a general feeling towards forking the server completely. But we need to decide something concrete, and this ML is dying down. I propose we have a voice/video chat with the objective of agreeing on a concrete plan both short term and for KF6 and then just going ahead and making the changes. Given Doodle's take forever and everyone's probably quarantined anyway, I propose we do it just after the Monday Plasma meeting. If someone is eager to share an opinion and can't make that, message here and we'll choose something more formally. David
Re: Problems in KWayland causes by API and ABI compatibility promises
FWIW I ported KDE Connect away from it here: https://invent.kde.org/kde/kdeconnect-kde/-/merge_requests/199 Leaving the rest as plasma-specific components. Aleix On Wed, Apr 1, 2020 at 2:04 PM 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) > > 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 > > David
Re: Problems in KWayland causes by API and ABI compatibility promises
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) 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 David
Re: Problems in KWayland causes by API and ABI compatibility promises
Hello, First, a big fat disclaimer: I'm by no mean expert in what's going on the Wayland side, so take what I'll be writing here with truck loads of salt. I'm jumping in mainly because it looks like you guys are in pain and I'm trying to lend a hand to find a way forward. It's obviously written from the "dealing with API overtime" point of view which includes horrible trade offs we get to make from time to time in KF. ;-) On Wednesday, 25 March 2020 12:16:58 CET Vlad Zahorodnii wrote: > On 3/24/20 4:35 PM, Aleix Pol wrote: > > 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. To be honest from the other emails I've seen in this thread I think Aleix is very much onto something. To me most of the pain points mentioned early in the thread are related to the library trying to do way too much (David's questions are illuminating in that regard as well). That's why trying to reduce the API surface and to focus the library as much as possible would be a good thing. Since kwaylandserver seems to be really only useful for kwin... no need to keep it in frameworks. > I was also thinking about splitting KWayland into KWaylandClient and > KWaylandServer. However, later on, I realized that this is a bad idea > because it'll make implementing new protocols more difficult and testing > wrappers will become more difficult. In fact, I don't think that we'll > be able to keep existing tests in the kwayland repo; we will probably > have to drop them. Sure, we're in a dire position so no solution will be easy. I understand the pain point will be the tests for kwaylandclient but maybe the situation is not that bad there. My gut feeling is that the current tests are done by testing kwayland against itself. So it's likely easy to miss issues with those tests. Couldn't a compositor stub be written just for the needs of kwaylandclient and run the tests against it? If you go low level enough you might even be able to test more error cases than before. It's an opportunity right there. The above raises a question of the amount of effort needed for such a stub (IOW, "how much API coverage should it provide?"). This is an obvious concern, and once again: the API surface matters. Is it me or even in kwaylandclient most of it is unused or not very much used? >From what was mentioned in this thread it looks like the users are not that numerous and that they each only use a couple of types or methods in there. Exception to this would likely only be kwin own unit tests. If I'm correct then next to moving kwaylandserver out, what about also moving everything of kwaylandclient which used only in kwin unit tests? Then that's less code to maintain and in turn that puts less pressure on the compositor stub used in the tests. > > 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. > > The problem is that we can't keep KWayland stable; at least, right now. Not saying it would be full proof but if the API shrinks as much as I'd expect it'd be easier to keep it stable. > There are still things in the wild that need a protocol or something and > as we implement those protocols, we might need some of existing wrappers > to adapt to the new changes or rework them completely. One such example > that comes to my mind is the explicit synchronization protocol. > > I think it's a good thing to have helper classes for Wayland protocols > that you could plug in and get a running compositor, this is a great > idea, but I think it's way too early to promise API and ABI guarantees. That said: I think for now it has to stay an idea, we can't have that in KF API not for the years to come. So... what's the course of action I have in mind really? I mentioned dropping stuff and we all know we can't really drop anything yet. Here are the steps I propose: 1) identify the few percents of the kwaylandclient API being used outside of kwin unit tests (might make sense to distinguish plasma-framework from other consumers BTW, we might apply different strategies for this one in case of roadblocks, not getting into this yet); 2) mark all of the kwaylandclient unused API as deprecated and freeze it; 3) write a compositor stub needed to exercise the non-deprecated API of kwaylandclient; 4) port the kwaylandclient tests to the compositor stub, dropping the tests about deprecated API; 5) take all of kwaylandserver + kwaylandclient and copy it to kwin (likely with a rename to avoid symbol clashes); 6) mark all of kwaylandserver API deprecated and freeze it;
Re: Problems in KWayland causes by API and ABI compatibility promises
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
Re: Problems in KWayland causes by API and ABI compatibility promises
Hi, On 3/24/20 4:35 PM, Aleix Pol wrote: 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. I was also thinking about splitting KWayland into KWaylandClient and KWaylandServer. However, later on, I realized that this is a bad idea because it'll make implementing new protocols more difficult and testing wrappers will become more difficult. In fact, I don't think that we'll be able to keep existing tests in the kwayland repo; we will probably have to drop them. 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. The problem is that we can't keep KWayland stable; at least, right now. There are still things in the wild that need a protocol or something and as we implement those protocols, we might need some of existing wrappers to adapt to the new changes or rework them completely. One such example that comes to my mind is the explicit synchronization protocol. I think it's a good thing to have helper classes for Wayland protocols that you could plug in and get a running compositor, this is a great idea, but I think it's way too early to promise API and ABI guarantees. Cheers, Vlad
Re: Problems in KWayland causes by API and ABI compatibility promises
I'll take care of it. It's still fixable within KF5 in the usual way. Let's follow up specifics of this on bug 419222 so we can keep this thread about the more general strategy. But it serves as a nice example to the type of problem we're facing. David
Re: Problems in KWayland causes by API and ABI compatibility promises
Hi, On 3/24/20 6:55 PM, David Edmundson wrote: I just had a near miss with XdgOutputV1(version2) which luckily we were able to easily guard. Had the spec claimed that in version2 sending xdg_output.name was mandatory we would have been completely screwed. Unfortunately, I have bad news. We're screwed. I poked people to clarify the language that is used in many specs. Here's the summary: if a spec says that an event is sent after creating an object and nowhere it says that the event is optional, then the compositor _must_ send the event. xdg_output::description is an optional event because the spec mentions it. On the other hand, xdg_output::name is mandatory because the spec has no a single word about it being optional. Cheers, Vlad
Re: Problems in KWayland causes by API and ABI compatibility promises
On mardi 24 mars 2020 17:55:48 CET David Edmundson wrote: > There's another problem we're going to hit with kwayland at some point > in the future. Sorry for hi-jacking, but there's another problem we're hitting right now in kwayland... There seems to be a nasty use-after-free in the testWaylandSurface unittest, which deletes the Registry even though some callback uses it later: https://build.kde.org/job/Frameworks/view/Platform%20-%20SUSEQt5.12/job/kwayland/job/kf5-qt5%20SUSEQt5.12/118/testReport/junit/projectroot.autotests/client/kwayland_testWaylandSurface/ -- David Faure Unittest police for KDE Frameworks 5
Re: Problems in KWayland causes by API and ABI compatibility promises
There's another problem we're going to hit with kwayland at some point in the future. KWayland specifies the protocol version. This means, according to framework policies we might have a released kwin which suddenly gets a new protocol version of something being announced. I just had a near miss with XdgOutputV1(version2) which luckily we were able to easily guard. Had the spec claimed that in version2 sending xdg_output.name was mandatory we would have been completely screwed. I'm seeing quite a few version bumps that change semantics coming up in wayland-protocols for other things. We either need the protocol version to be set from the compositor instead of kwayland or for kwayland to be more explicitly tied to kwin. David
Re: Problems in KWayland causes by API and ABI compatibility promises
On Mon, Mar 23, 2020 at 3:45 PM David Edmundson 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
Re: Problems in KWayland causes by API and ABI compatibility promises
> > 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
Re: Problems in KWayland causes by API and ABI compatibility promises
On 3/17/20 12:27 PM, David Edmundson wrote: IMHO we're lacking a "what actually is kwayland?" and an accurate definition of what's the added value compared to just using the auto generated classes directly. 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. 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. - Is it kwayland's job to abstract different versions of the same protocol? Yes. - Is it kwayland's job to abstract different protocols that are semantically similar? (including xdgshellv6 and wm_base) No. - Is it kwayland's job to turn an event-driven API into a property-driven API? (i.e turning the request set_minimum_size into an API where you can query what was last received) Yes. - Is it kwayland's job to abstract receiving double buffered stuff? (i.e the getter above only gets the value once committed) That's a difficult question. I can't answer it right now. - Is it kwayland's job to abstract sending double buffered stuff? (i.e implicitly send "wl_output.done() after Output::setSize()) Probably, not. - Is it kwayland's job to be a multiplexer? (i.e updating xdgoutput or plasmawindowmanagement forwards events to all listening resources) If so should we express this difference in the API or have them as methods on the global? Same for the sending to only the focussed window? Probably, yes. I'm not sure about the API part, though. - Is it kwayland's job to convert basic types into Qt friendly types? Yes. It's worth to point out that many wayland protocols are still being actively developed. So, some API design choices must be adjusted as we implement Wayland protocols. Cheers, vlad
Re: Problems in KWayland causes by API and ABI compatibility promises
On Tue, Mar 17, 2020 at 11:27 AM David Edmundson wrote: > > There's definitely a problem, and I think it's a lot more than just > discussing location and protocol versions. > > My typical workflow is reading the wayland protocol in detail, and > kwayland is in that awkward position where I absolutely still need to > read those underlying docs and the abstraction kwayland provides > frankly only doubles my workload. > > Taking a step backwards, there's a lot of parts of kwayland that are > very inconsistent. > > It looks like it's been written by 4 different devs all exploring > different ideas of how things should work...which isn't too surprising > given that's exactly what happened! > > IMHO we're lacking a "what actually is kwayland?" and an accurate > definition of what's the added value compared to just using the auto > generated classes directly. > > > > 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'd say the right question to ask is not what kwayland is but what we need it to be. When working on it, I sometimes feel it's about implementing wayland interfaces so they can easily be adopted by another Qt-based, not QtWaylandCompositor-based, Wayland compositor. > - Is it kwayland's job to abstract different versions of the same protocol? > > - Is it kwayland's job to abstract different protocols that are > semantically similar? > (including xdgshellv6 and wm_base) > > - Is it kwayland's job to turn an event-driven API into a property-driven API? > (i.e turning the request set_minimum_size into an API where you can > query what was last received) > > - Is it kwayland's job to abstract receiving double buffered stuff? > (i.e the getter above only gets the value once committed) > > - Is it kwayland's job to abstract sending double buffered stuff? > (i.e implicitly send "wl_output.done() after Output::setSize()) > > - Is it kwayland's job to be a multiplexer? > (i.e updating xdgoutput or plasmawindowmanagement forwards events to > all listening resources) > If so should we express this difference in the API or have them as > methods on the global? Same for the sending to only the focussed > window? > > - Is it kwayland's job to convert basic types into Qt friendly types? On all the above, I'd say the answer to all these we should set some expectations. In the end we should be creating the KWayland that is most useful for us. As a rule of thumb, I'd say it doesn't make sense to implement on KWayland things that won't be used outside of KWin, e.g. D26858. Aleix
Re: Problems in KWayland causes by API and ABI compatibility promises
There's definitely a problem, and I think it's a lot more than just discussing location and protocol versions. My typical workflow is reading the wayland protocol in detail, and kwayland is in that awkward position where I absolutely still need to read those underlying docs and the abstraction kwayland provides frankly only doubles my workload. Taking a step backwards, there's a lot of parts of kwayland that are very inconsistent. It looks like it's been written by 4 different devs all exploring different ideas of how things should work...which isn't too surprising given that's exactly what happened! IMHO we're lacking a "what actually is kwayland?" and an accurate definition of what's the added value compared to just using the auto generated classes directly. 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. - Is it kwayland's job to abstract different versions of the same protocol? - Is it kwayland's job to abstract different protocols that are semantically similar? (including xdgshellv6 and wm_base) - Is it kwayland's job to turn an event-driven API into a property-driven API? (i.e turning the request set_minimum_size into an API where you can query what was last received) - Is it kwayland's job to abstract receiving double buffered stuff? (i.e the getter above only gets the value once committed) - Is it kwayland's job to abstract sending double buffered stuff? (i.e implicitly send "wl_output.done() after Output::setSize()) - Is it kwayland's job to be a multiplexer? (i.e updating xdgoutput or plasmawindowmanagement forwards events to all listening resources) If so should we express this difference in the API or have them as methods on the global? Same for the sending to only the focussed window? - Is it kwayland's job to convert basic types into Qt friendly types? David
