XCB [was Re: Status of xserver/debrix/modular tree?]
otaylor at redhat.com
Thu Feb 10 20:50:21 PST 2005
Lars Knoll wrote:
>>>I don't understand the point you are trying to make here. You claim
>>>that QT and GTK are not "helping out", and then provide as evidence
>>>the fact that GTK and QT are both working with two very interesting
>>>new pieces of X-related infrastructure, (cairo and XCB). The evidence
>>>seems to support a conclusion that the toolkits are quite aware of
>>>what's going on and are participating.
> We're very much aware of these developments here and would for example love to
> move Qt over to XCB at some point. But to be able to do so I would first like
> to see Xlib being moved over to XCB. An XCB based Xlib is currently a
> prerequisite for being able to do this.
> There are several reasons for this. First it makes the transition a lot
> easier, as we could gradually replace XLib by XCB. another big reason is that
> several other libraries Qt relies on are still Xlib based. One of the more
> prominent examples are the GL libraries.
To echo, GTK+ is pretty much exactly the same situation.
The other reason that GTK+ needs Xlib-on-top-of-XCB is compatibility
with existing applications. It's common to mix a bit of raw Xlib code
into a GTK+ application. Such apps have to keep working with any
new version of GTK+.
An extremely useful excercise in the validation of the XCB interfaces
and their integration with Xlib-classic would be to take
gtk+/gdk/x11/gdkasync.c and rewrite it to use XCB while leaving the
rest of GTK+ using the standard Xlib interfaces. gdkasync.c uses
quasi-public interfaces in Xlib to do what should be much easier to
do with XCB.
An extremely useful excercise in validation of Xlib-on-top-of-XCB would
be to see if gdkasync.c works in it's current form on top of such a
More information about the xorg