Problems in KWayland causes by API and ABI compatibility promises

[David Edmundson]

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