Disclaimer: I've never followed XCB development, this may have all been discussed already, but I hope this post is at least helpful as a data point illustrating what I understood and didn't understand.
Julien Danjou was disappointed recently because after porting dbus-launch to XCB, we had a bit of a "what's the point?" reaction to the patch. Why move "#ifdef XCB" up into apps, when libX11 is already a compat layer that uses XCB if available?
However, XCB remains a useful idea. For the litl OS shell, we've discovered that we really need certain X requests to be async. I ended up digging into the XCB code to find an obscure bug. Since I'd just read a bunch of XCB code, I figured I'd try to expand on the API docs. Hopefully someone can fix up my docs efforts and land them upstream. (If you happen to notice bugs in my docs patch, please comment on the bug.)
Better docs ought to help people know when and how to use XCB. But the library could also benefit from two larger changes inspired by the higher-level desktop toolkits.
Heck, even server-side developers are piling on this bandwagon lately. XCB goes to a lot of trouble to support multithreaded operation. Unfortunately, multiple threads messing with UI code is highly problematic for most actual Linux toolkits and apps. (More conceptually: because X replies are always returned in request order, and the X server is single-threaded, everything is serialized anyhow...)
I filed a bug with my theory on what XCB needs for better main loop support. Please, comment on the bug with corrections and improvements.
I'd like to be able to queue a reply handler as a main loop callback, something that's difficult with XCB as it stands, unless I'm missing something.
XCB is in the pre-gobject-introspection school of binding implementation, i.e. libraries full of autogenerated stubs. (Not saying gobject-introspection invented dynamic stubs; COM and CORBA have it, as does Qt, doubtless many other things before that. But gobject-introspection is the GNOME version.)
I filed another bug proposing that XCB could export a binary "typelib" for the protocol. This could remove all request-specific code from non-C language bindings. It could make the C language bindings smaller, too. And it makes it easy to write debugging tools and code.
If the C bindings were dynamic, they could export two other flavors of each request without adding bloat: a "fire and forget" flavor that ignores both errors and replies; and a blocking, synchronous flavor (matching the convenience of libX11). These two flavors would be nice to have, without them XCB code can be more verbose than it ought to be. (It's a poor advertisement for XCB when the patch to go from libX11 to XCB adds extra lines of code, which happens most of the time when you make a request with a reply - at least two lines in xcb, vs. one in Xlib.)
An easy X protocol debug hook would be fantastic. xtrace doesn't provide easy customization for a particular debugging problem or particular application. I'm thinking something like:
void xcb_set_trace(xcb_connection_t *c,
xcb_trace_callback_t out_callback,
void *out_closure,
xcb_trace_callback_t in_callback,
void *in_closure);
Where I'm not sure yet if xcb_trace_callback_t should just take raw
bytes to be parsed by the app, or should be passed something
higher-level including sequence numbers and opcodes. A problem with
higher-level would be the need to parse the requests Xlib pushes
through xcb_writev() inside XCB. A potential middle road would provide
raw bytes to the trace callbacks, but export a simple X protocol
parser API that apps could use for tracing.
A trace hook wouldn't be as useful without exporting the protocol description "typelib" so apps and tools can make sense out of what they're seeing.
At the moment, for a single-threaded application XCB only helps you vs. Xlib in a narrow set of situations where you are willing to block on a reply eventually, but not right now. This is handy to "batch" requests as in the tutorial examples (search for useXCBProperly).
But XCB could offer much more, such as main loop async callbacks, dynamic language bindings, and debug/trace support. These are simple features to add to XCB, that would have been hard to add to the old libX11 codebase.
Just a bit more "what's in it for me?" would be helpful when it comes to convincing apps and toolkits to port over to XCB.
While I'm posting: it seems to be hard (impossible?) to use libxcb-glx because libGL doesn't export a way to get or set the context tag. Not sure where to file this bug or if I'm just missing something.