[Xcb] Re: gtk, to xcb or not

[Jamey Sharp]

On Thu, Nov 09, 2006 at 03:07:26PM +0800, Yang JianJun wrote:
> On 11/8/06, Havoc Pennington <hp at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20061109/94bf47c8/attachment.pgp