Problems in KWayland causes by API and ABI compatibility promises

[Aleix Pol]

On Tue, Mar 17, 2020 at 11:27 AM David Edmundson
<david at davidedmundson.co.uk> 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