Re: GTK-XCB is in progress

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 ;-)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]