Re: Problems in KWayland causes by API and ABI compatibility promises

Am 2020-03-05 13:21, schrieb Vlad Zahorodnii:
> 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 historic context I want to add that we made KWayland an ABI stable 
framework before the unstable-mess of Wayland protocols happened. If 
I/we would have foreseen this problem we would probably have addressed 
this differently. Some of the unstable protocol changes really took me 
by surprise and I had no idea how to handle it at all. Most negative 
example was Qt creating a proprietary input method protocol using the 
official name.

Luckily frameworks 6 is approaching which gives us a chance to address 
it.

I fully agree that the current situation is not good and won't scale for 
future. For me it was clear that we have to clean up with the next ABI 
break. Somehow I sneaked out of the mess prior to doing the cleanup - 
sorry. (I still hope to find time again to do coding, at least I have 
sufficient time to write long mails :-P )

Personally I would suggest to keep KWayland in frameworks. It is a 
powerful framework and I still see needs outside of Plasma - especially 
as QtWayland Compositor is going GPL only. I would still love to see QML 
bindings for it. Also what served KWin really well was having the X 
abstracting in KWindowSystem which was a driving factor for me to have 
the KWayland library split out of KWin and provide it as a framework. 
And it's always the joker in case we think we want to start over and 
write a new wayland only window manager.

Being in frameworks means we cannot cleanup - except for ABI breaks. On 
the other side we cannot cleanup anyway - it's a wishful thinking to 
hope to only have to support one version of a protocol. This was 
something I didn't expect to be so bad in practice. Due to distributions 
not moving everything at the same time we have various toolkits running 
different versions of the protocols. I rather doubt that this will 
improve.

Somewhere in the stack we need the compatibility.

My suggestion would be the following:

  * only stable protocols get abstracted the way they are today
  * unstable protocols get the UnstableVX in their class name and get the 
code copied
  * as soon as a new unstable version gets supported the abstraction for 
the previous class gets deprecated
  * KWin can support multiple versions, although that means more work on 
KWin side, but it also creates pressure to drop support for the old code 
- which is a good thing


Cheers
Martin