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
Re: Problems in KWayland causes by API and ABI compatibility promises
On 3/6/20 12:55 AM, Kai Uwe Broulik wrote: Frameworks: === Looks like just Plasma Dialog in Plasma-Framework, for which I believe KWayland was turned into a Framework to begin with. Other: == - Spectacle - Yakuake - Latte Dock (presumably similar uses as plasmashell) Some of the above uses potentially have Qt upstream and/or KWindowSystem API nowadays without the need to use lowlevel KWayland calls. I think Vlad was porting away a bunch of now superfluous KWayland uses in e.g. Breeze. Yeah I guess if we can port the apps and Plasma Dialog away, we could make it live in KWin again. Anyway, just a thought from a non-technical-expert in this code. :) Nate
Re: Problems in KWayland causes by API and ABI compatibility promises
Am 05.03.20 um 17:27 schrieb Nate Graham: What are the known users of KWayland outside of KWin? Are there any? Quick lxr suggests there's actually a bunch: In Plasma (for which we could do an "integration" library without Frameworks guarantees in plasma-workspace, similar to e.g. LibTaskManager or LibKWorkspace): = - XDG Desktop Portal Wayland Integration - PowerDevil for DPMS (display power management) on Wayland - Plasmashell (for panels, desktops, logout dialog, task manager, virtual desktops, potentially global menu and much more) - Plasma phone and nano components - KRunner - KScreen - KScreenLocker - KInfoCenter (some wayland info module presumably) - Oxygen and Breeze (probably the "start system resize" which Qt 5.15 has upstream iirc and window shadows which KWindowSystem can now do) - KWayland Integration (plug-ins for stuff in frameworks like KIdleTime, KWindowSystem that cannot depend on KWayland). It's not a consumable API, though, just plug-ins. Frameworks: === Looks like just Plasma Dialog in Plasma-Framework, for which I believe KWayland was turned into a Framework to begin with. Other: == - Spectacle - Yakuake - Latte Dock (presumably similar uses as plasmashell) Some of the above uses potentially have Qt upstream and/or KWindowSystem API nowadays without the need to use lowlevel KWayland calls. I think Vlad was porting away a bunch of now superfluous KWayland uses in e.g. Breeze. Cheers Kai Uwe
Re: Problems in KWayland causes by API and ABI compatibility promises
Moving it into KWin itself seems sane to me, on the surface. What are the known users of KWayland outside of KWin? Are there any? Nate On 3/5/20 5:21 AM, Vlad Zahorodnii wrote: Hi, KWayland is a library that provides convenience wrappers for Wayland protocols. Usually, when we want to implement some Wayland protocol, first, we add corresponding wrappers in KWayland and after that we actually implement the protocol in KWin. Unfortunately, we made a bad design choice in KWayland. It is common in KWayland to see abstractions over unstable protocols. We do it in the name of "don't repeat yourself" principle. This reduces the amount of duplicated code in KWin, but it also makes much more difficult to extend KWayland. Abstracting unstable protocols turns out to be really bad when the next version of an unstable protocol contains big changes, e.g. xdg-shell-unstable-v5 -> xdg-shell-unstable-v6. Due to the API and ABI compatibility promises, we can't fix the broken design of those wrappers. We should not try to abstract over Wayland protocols in the first place! We need to fix those wrappers in order to implement the corresponding protocols properly in KWin (and fix a few bugs). One option is to make KWayland unstable so we are free to do necessary changes to fix the wrappers, but it doesn't really go along with the Frameworks' policies. Another option is to move KWayland somewhere else, e.g. KWin or Plasma. Alternatively, we could provide new wrappers and append a suffix to class names, e.g. "2" or "V2". But I don't like this approach for a couple of reasons. First, we are going to mix two types of versions in a single class name, e.g. XdgToplevelV6InterfaceV2, etc. Second, some protocols are not completely implemented in KWin, so we may still need to change wrappers in a way that may break API or ABI compatibility. Arguably, we just don't have to push semi-finished changes, but implementing everything all at once is a bit difficult and tackling one problem at a time is much easier. I'm writing this email to bring problems that we currently have in KWayland up to discussion and find the way in which we can address them. For what it's worth the question of moving KWayland out of Frameworks to somewhere else had been raised before, but the discussion got stalled... sort of. [1] Cheers, Vlad [1] https://phabricator.kde.org/T11903
Problems in KWayland causes by API and ABI compatibility promises
Hi, KWayland is a library that provides convenience wrappers for Wayland protocols. Usually, when we want to implement some Wayland protocol, first, we add corresponding wrappers in KWayland and after that we actually implement the protocol in KWin. Unfortunately, we made a bad design choice in KWayland. It is common in KWayland to see abstractions over unstable protocols. We do it in the name of "don't repeat yourself" principle. This reduces the amount of duplicated code in KWin, but it also makes much more difficult to extend KWayland. Abstracting unstable protocols turns out to be really bad when the next version of an unstable protocol contains big changes, e.g. xdg-shell-unstable-v5 -> xdg-shell-unstable-v6. Due to the API and ABI compatibility promises, we can't fix the broken design of those wrappers. We should not try to abstract over Wayland protocols in the first place! We need to fix those wrappers in order to implement the corresponding protocols properly in KWin (and fix a few bugs). One option is to make KWayland unstable so we are free to do necessary changes to fix the wrappers, but it doesn't really go along with the Frameworks' policies. Another option is to move KWayland somewhere else, e.g. KWin or Plasma. Alternatively, we could provide new wrappers and append a suffix to class names, e.g. "2" or "V2". But I don't like this approach for a couple of reasons. First, we are going to mix two types of versions in a single class name, e.g. XdgToplevelV6InterfaceV2, etc. Second, some protocols are not completely implemented in KWin, so we may still need to change wrappers in a way that may break API or ABI compatibility. Arguably, we just don't have to push semi-finished changes, but implementing everything all at once is a bit difficult and tackling one problem at a time is much easier. I'm writing this email to bring problems that we currently have in KWayland up to discussion and find the way in which we can address them. For what it's worth the question of moving KWayland out of Frameworks to somewhere else had been raised before, but the discussion got stalled... sort of. [1] Cheers, Vlad [1] https://phabricator.kde.org/T11903
