On Thu, Nov 09, 2006 at 03:07:26PM +0800, Yang JianJun wrote: > On 11/8/06, Havoc Pennington <hp redhat com> wrote: > >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. > > 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. So here's the "official" story on porting Xlib-based apps and libraries to XCB. We understand that the whole world can't migrate to XCB all at once -- in some cases, it may be that nobody can find the source code needed to do the port. We also understand that dual parallel maintenance is not feasible. That's why we've produced a version of Xlib that enables incremental migration to XCB, called Xlib/XCB, which we expect to be included in the X.org 7.2 release. Assuming a project is willing to require the new version of Xlib, then avoiding dual-maintenance hell is easy. The Xlib-specific interfaces (in this case, gdkx.h) can still be provided; they become simple wrappers that first convert Xlib types to XCB types with help from libX11-xcb, then call into the XCB version of the same code. [1] For many of the functions in gdkx.h this is really boring, because they don't expose any Xlib types. Others expose Xlib types that have the same representation in XCB, such as gdk_x11_screen_lookup_visual which takes a VisualID, but that's identical to xcb_visualid_t. In all these cases, the gdk_x11 names should probably just be aliases for the equivalent gdk_xcb names. The only hard part here is that several of these functions return a value of some Xlib type (Display*, for instance) given a GDK type. If the GDK type stores only an XCB type (XCBConnection*) then constructing a corresponding Xlib value is quite hard, and we don't support it. So if these gdk_x11 functions are to be used, they must be applied to GDK values that were constructed from Xlib types in the first place. Whatever the details, GDK can be ported while Gtk+ and Gnome continue to use Xlib APIs, and porting those higher-level libraries can happen by the same strategy of providing small wrappers anywhere that Xlib types appear in the public API. In the case of cairo, I haven't been inclined to suggest that it require the new version of Xlib yet, since X.org 7.2 isn't out yet. [2] So we've been maintaining the Xlib and XCB backends separately, by copy-paste. We're starting to find places where the implementation is independent of Xlib or XCB, and so Ian Osgood and I have some preliminary work to factor such code out, but much more work remains. I hope that with the release of X.org 7.2, projects like cairo and Gtk+ will be willing to do new development using the new version of Xlib, and we can begin a widespread porting effort. How would the Gtk+ developers feel about such a move? --Jamey [1] Ideally, only the Xlib wrappers would be in the library under the old .so name -- the XCB based implementation would get a new library name, so ABI compatibility is maintained but you can track symbol dependencies properly. [2] And because the cairo-xcb backend has existed for almost as long as cairo has had support for multiple backends -- not a coincidence -- which is rather longer than we've had a viable migration plan.
Attachment:
signature.asc
Description: Digital signature