[Xcb] splitting xcb/util

[Jamey Sharp]

On Fri, Jul 16, 2010 at 8:43 PM, Michael Stapelberg
<michael+xcb at stapelberg.de> wrote:
> Excerpts from Jamey Sharp's message of 2010-07-17 02:45:50 +0200:
>> If you can explain what's you're actually finding hard about the code
>> you're writing, perhaps then we can discuss what to do about it? I'm
>> always happy to explore better APIs.
> Well, I need to handle the response_type of an event myself which involves
> several assertions and a bitwise operation which is unclear to me yet (why
> is it necessary?). Also, it’s about 20 lines of boilerplate code which does
> not actually handle any event. In my opinion, it could well be hidden in a
> library.

You only really need to do two things: check whether this is an error or
event, and if it's an event, mask off the SendEvent bit. That
most-significant bit of the response type indicates whether the event
was generated by the server or is being forwarded from another client.
It's just part of the X protocol, and like most of the important details
of XCB programming, it's documented in the X protocol specification.

You don't need to assert that an 8-bit value is less than 256, and I
wouldn't bother with the other assertions either.

That leaves you with a pretty simple structure in your event loop. If
you want to use if statements instead of switch, which certainly has the
advantage of handling extension events more smoothly, you might do it
this way:

if(event.response_type == 0)
{
    /* handle errors; you're doing this with: */
    exit(1);
}
uint8_t type = event.response_type & 0x7F;
if(type == XCB_EXPOSE)
    handle_expose_event();
else if(type == XCB_KEY_PRESS)
    ...
else
    /* this case would fire harmlessly if any of your asserts would */
    printf("WARNING: unhandled event of type %d\n", event.response_type);

To me, this seems clear, handling each type of response with minimal
boilerplate.

Jamey