On 11/8/06, <b class="gmail_sendername">Havoc Pennington</b> <<a href="mailto:hp@redhat.com">hp@redhat.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>It seems pretty clear that gtk-x11 has to continue to be installed -<br>gdkx.h is in the ABI.</blockquote><div><br>XCB is a replacement for Xlib, so if we contribute the gtk-xcb backend, it should replace gtk-x11. Accordingly, there is
gdkxcb.h, instead gdkx.h. However, gtk-xcb cannot provide the compatibility, because of the new gdkxcb.h. The gtk-based application have used gdkx.h, and want to link to gtk-xcb also, it must migrate to use XCB API. Otherwise, you may use Xlib/XCB for compatibility, not the X11-Free-Gtk.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">That means a path forward would have to make maintaining both XCB and<br>libX11 GDK targets a viable option,
i.e. just cut-and-pasting the X11<br>backend and modifying it to be the XCB backend is not feasible. Instead,<br>for the next many years GTK+ would install a gtk-x11 and a gtk-xcb.</blockquote><div><br>I ported like that just as the fist step. Sharing codes between the two X backend is not an easy problem. Also I think gtk-x11 and gtk-xcb should not coexistence.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The simplest path to have both seems to be to have an abstraction API<br>that could use libX11 or XCB on the backend. Doesn't XCB have a
<br>libX11-like wrapper API? If so, why not make that the abstraction API?<br>If not, why not write one that implements what gdk-x11 uses? So an XCB<br>backend shares virtually all code with the libX11 backend and the libX11
<br>backend is pretty much unchanged.</blockquote><div><br>The XCB API is entirely different from Xlib, it supports latency hiding. XCB would not provide som x11-wrapper API, i think. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In the public XCB API (gdkxcb.h vs. gdkx.h) native XCB API could be<br>used, and gdk-xcb would not support gdkx.h or would support it only with<br>footnotes and caveats. This would allow apps to migrate to a<br>libX11-API-free state by requiring the xcb backend and using
gdkxcb.h<br>instead of gdkx.h.<br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The resulting gtk-xcb would give people the ability to avoid installing
<br>libX11 on embedded devices, and would give a shot at thread safety<br>(though gdk and gtk aren't threadsafe anyway).</blockquote><div><br>Now gtk-xcb has arrived the goal. Peple who use gtk need not install
libX11 any more. And gtk-xcb have its own gdkxcb.h, I just have not
rename it:) </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Whether it's worth all the pain, I really don't know though ;-)</blockquote>
<div><br>I would like to know whether gtk-team has the plan for xcb port.<br>Anyway, thanks for your suggestions!<br><br>Jianjun<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Havoc<br><br>_______________________________________________<br>gtk-devel-list mailing list<br><a href="mailto:gtk-devel-list@gnome.org">gtk-devel-list@gnome.org</a><br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list">
http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br></blockquote></div><br>