[Xcb] how to use the record extension in xcb...

[zmqdev]

Hello,

I'm currently writing a new version of a (working) program that uses the
record extension, so I want to use xcb instead of Xlib.

However, I am unclear on how to separate the multiple items contained in
a single reply from the record extension.

The only working example I found was this answer on stackoverflow

https://stackoverflow.com/questions/20823894/xcb-record-x11-extension-example

It works, but does 'magic' to access the several data items that are
contained in a single xcb_record_enable_context_reply_t (as per protocol
specification of record extension).

I thought of iterator functions, but for some reason, the header file
<xcb/record.h> has only the one function

xcb_generic_iterator_t
xcb_record_enable_context_data_end (const
xcb_record_enable_context_reply_t *R /**< */);

and no xcb_record_enable_context_data_iterator or
xcb_record_enable_context_data_next.

How does the 'magic' of the example work?
How I do I access all the data contained in a single reply?

Cheers.

[Uli Schlachter]

Post by zmqdev
Hello,
I'm currently writing a new version of a (working) program that uses the
record extension, so I want to use xcb instead of Xlib.

I'm sorry to hear that.

Post by zmqdev
However, I am unclear on how to separate the multiple items contained in
a single reply from the record extension.
The only working example I found was this answer on stackoverflow
https://stackoverflow.com/questions/20823894/xcb-record-x11-extension-example
It works, but does 'magic' to access the several data items that are
contained in a single xcb_record_enable_context_reply_t (as per protocol
specification of record extension).

It does the same magic that libXtst uses to parse the reply.

Post by zmqdev
I thought of iterator functions, but for some reason, the header file
<xcb/record.h> has only the one function

The XCB header functions are auto-generated from the protocol
description and the RECORD extension does not really fit into this. Its
replies can contain almost arbitrary data. I think the XML used to
express protocol extension is not powerful enough to express RECORD's
magic and even if it were, the generated result would not be all that
usable.

I think that all that I can tell you is to stick with Xlib instead of
XCB when using the RECORD extension.

Uli
(who also wrote the above-linked stackoverflow answer)

[zmqdev]

(...)

Post by Uli Schlachter
The XCB header functions are auto-generated from the protocol
description and the RECORD extension does not really fit into this. Its
replies can contain almost arbitrary data. I think the XML used to
express protocol extension is not powerful enough to express RECORD's
magic and even if it were, the generated result would not be all that
usable.

makes sense

Post by Uli Schlachter
I think that all that I can tell you is to stick with Xlib instead of
XCB when using the RECORD extension.

I do miss XRecordEnableContentAsync and XRecordProcessReplies.

Fortunately, only a few events are of interest.

I am considering handling the data connection in a separate thread.

Post by Uli Schlachter
Uli
(who also wrote the above-linked stackoverflow answer)

thanks for that post!

[o. krajka]

(...)

Post by Uli Schlachter
The XCB header functions are auto-generated from the protocol
description and the RECORD extension does not really fit into this. Its
replies can contain almost arbitrary data. I think the XML used to
express protocol extension is not powerful enough to express RECORD's
magic and even if it were, the generated result would not be all that
usable.

makes sense

Post by Uli Schlachter
I think that all that I can tell you is to stick with Xlib instead of
XCB when using the RECORD extension.

I do miss XRecordEnableContentAsync and XRecordProcessReplies.

Fortunately, only a few events are of interest.

I am considering handling the data connection in a separate thread.

Post by Uli Schlachter
Uli
(who also wrote the above-linked stackoverflow answer)

thanks for that post!