[Xcb] Experiences with XCB

[Jamey Sharp]

Thanks for the report, Ori! As we approach a release finally, it would
be nice to get some more of these. Though I don't know that we could do
much with them at this point besides give up and go home if people's
experiences are really awful... :-/

On Wed, 20 Sep 2006, Ori Bernstein wrote:
> My experience with XCB was mixed. My first thought was "Where are the
> docs?!?".

Heh. I sympathize, kind of. But were you looking for documentation on
protocol stubs, or on the core API? We've had pretty OK documentation on
the core API for more than a year, and of course the protocol stubs are
rather exhaustingly documented by the relevant protocol specifications.
While we intend to integrate all of that documentation together
eventually (actually, we're really just waiting for a volunteer to just
do it), are you saying that wouldn't have helped you? Everything we plan
to provide was available to you already, after all... :-)

> The "strong typing by structs" was another annoyance, although I guess
> my use case is nontypical, since I had to interact with the X server's
> DIX, which uses scalars. Lots of conversions were going on.

Yeah, that is a bit unusual. :-)

> I still believe the biggest deficiency in the XCB API is that there is
> no way to peek the next event in the queue. An example use case: I
> want to collect all expose events in one function. In my mind, the
> natural way to do this is peeking the next event (or at least it's
> type) to decide if I'm done gathering exposures. XCB has no way of
> doing this, as far as I can see, and it makes some code awkward.

On Wed, Sep 20, 2006 at 08:10:35AM +0200, Vincent Torri wrote:
> I also have dealt with that in ecore. But I modified a bit my code
> and, finally, that peek function was not necessary for me. In case it
> might help you, I get the next event and store it in a global
> variable, and I use that variable later to check of there's an event
> or not in the queue.

Yeah, if the application *has* to peek in the event queue, then this is
the way I would do it. Although for ecore, Vincent, beware of assuming
that there is only one connection open to an X server. I hope ecore
doesn't currently assume that... :-)

It still seems to me that the best way to accomplish things like expose
events, though, is to process events centrally into application-specific
data structures, drain the event queue entirely, and then do any
expensive drawing or computation that the events trigger. Then you
*know* there aren't more expose events, and can already have collapsed
the ones you got into a single region if desired.

> Usually, when I don't find enough doc on how to translate an Xlib
> function in the tutorial, I look at the Xlib code. It's usually easy,
> then to get the XCB code.

Hmm. Your approach is sound, but somewhat frightening. ;-)

> In gneral, you are right, there is a lack of doc about xcb. Once the
> naming convention will be out, I think that I'll make a patch so that
> doc is generated by doxygen if it is found.

We should be able to run doxygen at freedesktop.org on a regular basis,
and keep the generated pages at http://xcb.freedesktop.org. We're ready
for that now, I think: I'm again hoping a volunteer will step up to take
care of it. :-)

--Jamey
-------------- 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/20060919/acb04227/attachment.pgp