Re: GTK-XCB is in progress

[Havoc Pennington <hp redhat com>]

Ross Burton wrote:
> > I'd say thread-safety.
>
> And the ability to not link to libX11, which is relatively huge.

It seems pretty clear that gtk-x11 has to continue to be installed - 
gdkx.h is in the ABI.

That means a path forward would have to make maintaining both XCB and 
libX11 GDK targets a viable option, i.e. just cut-and-pasting the X11 
backend and modifying it to be the XCB backend is not feasible. Instead, 
for the next many years GTK+ would install a gtk-x11 and a gtk-xcb.

The simplest path to have both seems to be to have an abstraction API 
that could use libX11 or XCB on the backend. Doesn't XCB have a 
libX11-like wrapper API? If so, why not make that the abstraction API?
If not, why not write one that implements what gdk-x11 uses? So an XCB 
backend shares virtually all code with the libX11 backend and the libX11 
backend is pretty much unchanged.

In the public XCB API (gdkxcb.h vs. gdkx.h) native XCB API could be 
used, and gdk-xcb would not support gdkx.h or would support it only with 
footnotes and caveats. This would allow apps to migrate to a 
libX11-API-free state by requiring the xcb backend and using gdkxcb.h 
instead of gdkx.h.

The resulting gtk-xcb would give people the ability to avoid installing 
libX11 on embedded devices, and would give a shot at thread safety 
(though gdk and gtk aren't threadsafe anyway).

Whether it's worth all the pain, I really don't know though ;-)

Havoc