A major blocker could be that it relies on my "poser" project: https://github.com/Zirias/poser ... it's a small lib, so you could certainly integrate the parts needed, but I didn't do it, I just made #Xmoji build with a bundled (statically linked) #poser by default instead. Another blocker could be that it does quite some trickery to force #xcb into an #async model with #events and registered event-handlers (provided by poser), so it integrates well with a generic event loop built on #select (which poser does, anything else based on file descriptors like #poll, #epoll, #kqueue would work as well). It abuses xcb functions meant for tracing/debugging for that purpose. 🙈

And then, of course, it's very different from #Xt. It strictly requires #XRender, using its "picture" objects as the primary drawing handle, and just offering the core X11 "drawable" on demand. It strictly requires a "true color" visual. It has NO support whatsoever for core drawing primitives and core (bitmap) fonts. It doesn't create a window for every widget but instead manages widgets fully client-side ... all these are probably not "blockers" but just how you'd design a GUI toolkit for X11 nowadays 😉