[Xcb] Tiny cleanup patch that removes some code duplication

[Barton C Massey]

In message <314085.88611.qm at web59907.mail.ac4.yahoo.com> you wrote:
> I'm sort of new to the xcb code. Can you maybe explain what
> kind of work arnaud is doing on his xcb-utils branch? Also,
> how does it impact/obsolete my cleanup patch?

I don't know that it obsoletes it so much, but there will
maybe be a merge involved.

> 1) I've introduced a utility function "get_atom" in both
>    flames and julia demos, maybe there should be a
>    synchronous helper function like that added to xcb-utils
>    or somewhere (for use in non-perf critical paths only
>    ofc)??

A patch would be welcome.

> 2) Also, I've seen code like this on several places (see
>    below). In this context, why is 0x7f used? Is there a
>    constant for this instead or maybe the API could be made
>    a little bit clear/readable?

>       if ((e = xcb_poll_for_event (f->xcb.c)))
>        {
>           switch (e->response_type & 0x7f)

We probably should let the constant 0x7f creep into xcb.h,
even though technically it doesn't belong there since it has
no name in the protocol spec AFAIK.  Call it something like
XCB_EVENT_RESPONSE_TYPE_MASK, I guess.

It's accounting for the fact that the high bit of the
response_type will be 1 if the event is a synthetic event
(generated by a SendEvent request) rather than an event
generated by the server; this is not something applications
normally want to know.

If you want to confuse everyone, just use XCB_NO_OPERATION
as the mask. :-) :-)

    Bart