XCB [was Re: Status of xserver/debrix/modular tree?]

[Owen Taylor]

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
library. :-)

Regards,
						Owen