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
