[Xcb] best practices for porting to XCB

[Jamey Sharp]

On Thu, Mar 25, 2010 at 10:30 AM, Julien Danjou <julien at danjou.info> wrote:
> Josh Triplett <josh at joshtriplett.org> writes:
>> Trying to support both Xlib and XCB in the same library without relying
>> on Xlib/XCB would necessarily require duplicate code paths, one using
>> XCB calls and one using Xlib calls; that seems like a losing plan.
>
> Already done that in libstartup-notification. :-(

Yeah, Josh and I looked at that the other day. It's really cool that you
added support for XCB to libstartup-notification! But it sure looks like
it was painful to write. I hope that most library porting efforts can
take a less-difficult route.

>> ...current Cairo has a --with-xlib-xcb option that makes the Xlib
>> backend call XGetXCBConnection and use the XCB backend. :)
>
> I love that. They should drop Xlib support! (Carl, if you're reading… :-)

They're getting there! Chris Wilson is doing most of the work of getting
cairo's XCB backend to feature and performance parity with the Xlib
backend. As usual, there are probably opportunities to help still. :-)

> OTOH, taking a look at libxcursor and libxft, they both use Display and
> no context pointer.

I don't see anything really hard about that. It just means you have a
bunch of very small stub functions, which might look like this:

Cursor
XcursorImageLoadCursor (Display *dpy, const XcursorImage *image)
{
	return XCBcursorImageLoadCursor(XGetXCBConnection(dpy), image);
}

There might be slightly more code involved if you need to convert types
like XcursorImage or Cursor.

This is obviously the kind of thing that ought to be machine-generated.
For example, before coming up with the current Xlib/XCB implementation,
I followed a strategy like this in Xlib itself--we called that XCL. Some
of those stubs had to be hand-written, but many were generated with m4.

In fact, a student contacted me recently, wanting to demo a stub-code
generator he's writing by building an equivalent of XCL. I don't think
he has a web page or anything that I can point to yet, but I'm hopeful
that we'll get tool support for this style of library porting.

> So I'm not sure what to do. I'd be happy to add a context to thus libs
> and break the API, but I'm not sure I'd be welcome. Maybe I should talk
> to upstream before losing my time.

No matter what, you're going to break at least part of the API for
people who want to use XCB. The trick is to offer the old API alongside
the new one, so you don't force anyone to port their code before they're
ready.

In my ideal world, the new API would be provided by a different library
than the old one, so that you can quickly tell which interface your
application needs. You need to ensure that both libraries can be loaded
in the same program though, which I hear means either using a different
library name or using symbol versions.

Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20100325/d03fa1df/attachment.pgp>