[Xcb] X.Org app dependencies on xcb-util libraries

[Jamey Sharp]

On Thu, Jun 24, 2010 at 8:29 AM, Julien Danjou <julien at danjou.info> wrote:
> On Thu, Jun 24 2010, Alan Coopersmith wrote:
>> One question remaining before I push my xwininfo port to xcb - are we
>> okay with stable bits of the X.Org katamari depending on the unstable
>> libraries from xcb-utils?   This uses xcb-event & xcb-icccm -
>> obviously both could be replaced by inlining the necessary support,
>> but code duplication kills maintainers, so it's not my preferred
>> solution.
>
> xcb-icccm should be stable now, I don't think it will change anytime
> soon. Not so sure about xcb-event tho, I can't recall what was the
> final decision about it, but IIRC, that my point of view was DIE DIE
> DIE, except for the some #define that should be in XCB itself.

The giant thread started here:
http://lists.freedesktop.org/archives/xcb/2010-March/005738.html

In that thread somebody pointed out that xcb-icccm isn't properly
namespaced, so it's possible it'll go through a trivial sed renaming.
It's also possible that it'll merge with xcb-ewmh. (Which doesn't seem
to be available anywhere beside's Arnaud's personal repo?) So I think
the question of whether the katamari can depend on this library is
relevant.

Alan, you can drop xwininfo's most important dependencies on xcb-event
by using the event and error code #defines from XCB instead. They have
less wisely chosen names, but are certainly stable. Also, I wouldn't
feel bad about just inlining XCB_EVENT_RESPONSE_TYPE(e): it simply masks
the event's response_type against 0x7f, as the protocol requires, to
strip the SendEvent flag off. I guess I also wouldn't feel bad about
copying that macro to xcb.h.

The remaining bit that you're using, to look up names of the core
protocol requests and errors, is just to print X errors in a form
resembling Xlib's default error handler. That doesn't seem critical to
xwininfo's operation, so I'd suggest just dropping the dependency on
xcb-event entirely.

Note that the XCB_EVENT_MASK_* values you're using are coming from XCB,
not xcb-event, despite the appearance of namespacing.

Julien, when I wrote the first version of xcb-event, it contained only a
sample callback-based event loop, which I would definitely say should
die, as should the sample callback-based reply loop in the xcb-reply
library, and the sample callback-based property loop in xcb-property.
Yes there's a theme here.

Jamey