On Tue, 2006-11-07 at 13:21 -0500, Havoc Pennington wrote:
> It seems pretty clear that gtk-x11 has to continue to be installed -
> gdkx.h is in the ABI.
Damn. So it is.
> 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.
There is work on porting libX11 to use XCB internally, which is probably
what you are thinking of.
>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.
This sounds good to me. Would deprecating gtkx.h be considered when XCB
is sufficiently deployed?
Ross
--
Ross Burton mail: ross burtonini com
jabber: ross burtonini com
www: http://www.burtonini.com./
PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
Attachment:
signature.asc
Description: This is a digitally signed message part