I see C in there; that's cheating ;) (my WM uses a pure-Ruby X11 client library - there are no external C dependencies other than those of the Ruby implementation itself).

Though I sympathise - the sheer amount of effort to work with these, be it X11 or Wayland, is really annoying; the pure Ruby X11 gem I use is more lines of code than the window manager itself...

Yeah, I link against C libs because reimplementing the protocol seemed like a pain in the ass. The prevailing strategy seems to be to generate code based on XML protocol specs, and I'd prefer to avoid that crap. That would probably be less painful in Ruby as then the code could just be generated at runtime based on the XML.

Also since all the prepackaged wayland libs are heavy users of functions declared as `static inline` I have to create shims for those as they are not linkable. That part is a pain in the ass but pretty simple to resolve :)

And yeah, there is so much to set up just to get a bare minimum going. I guess that would be true in X11 too.

Oh, I absolutely don't judge you for those. Frankly part of the reason I went for a pure Ruby version instead of xlib was that the Xlib bindings for Ruby are also in an awful state, and someone else had done enough of the job on the pure Ruby bindings that it felt like it was doable incrementally as I needed various calls and not much worse than wrapping Xlib or xcb.

I like that there are no other dependencies, but I'd have sacrificed that if it was sufficiently much easier than the route I ended up taking (e.g. my terminal did start out linking to Xlib and using a tiny C extension; it's since been ripped out in favour of the pure Ruby bindings, since why not now that it's available, but it was a perfectly ok solution to start with).

Parsing all those XML specs at runtime seems really slow and wasteful, surely this there’s a better way, no?

The code generation is certainly a build step. This kind of code generation is common for interfaces defined outside of a project's programming language.