Problems in KWayland causes by API and ABI compatibility promises

Vlad Zahorodnii vladzzag at gmail.com
Wed Mar 18 12:34:19 GMT 2020


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


More information about the Kde-frameworks-devel mailing list