Re: Porting GDK to use XCB on the backend

[Travis Spencer <travislspencer gmail com>]

On 6/22/05, Mike Emmel <mike emmel gmail com> wrote:
> On 6/22/05, Owen Taylor <otaylor redhat com> wrote:
> > Note to start off with that for compatibility reasons, GTK+ needs to
> > keep linking to Xlib and exporting gdkx.h. This means that making GTK+
> > use XCB is something that can only done within the context of an Xlib
> > that uses XCB internals.

OK.  That was what I was indending to do after reading your previous
posts on the matter, Owen.

> > It would be possible to do an XCB backend from GTK+ that is independent
> > from the current Xlib backend and doesn't try to present compatibility,
> > but that's clearly a bad idea for the desktop. 

Agreed.

> Its my understanding that the issue of Xlib/xcb compatibility has been
> solved there exists some sort of xlib on xcb library or at least proof
> of concept. I think this approach if it exists our could be built
> would solve the migration and support problems. Anything to kill xlib
> is good stuff IMHO :)

Ya, it does exist.  Check the section "Xlib on XCB" at
http://xcb.freedesktop.org/wiki/xcb.

> > gdkasync.c is interesting because it is code that can actually take
> > advantage of XCB. It's using Xlib "internals" in order to reduce
> > round-trips to the X server. This works OK, other than some thread
> > safety problems, but it is very messy. XCB (with some improvements)
> > could be used to do this in a much cleaner way.
> >
> > Another nice thing about gdkasync.c is that it would be easy to have
> > a conditionally compiled gdkasync-xcb.c that was used only when
> > GTK+ was compiled against an Xlib with XCB internals.

Thanks for the info.  I think this is enough to get going.  

-- 

Regards,

Travis Spencer
Portland, OR USA