[Xcb] xcb pre-release
Thien-Thi Nguyen
ttn at gnuvola.org
Fri Jul 18 00:08:15 PDT 2008
() Barton C Massey <bart at cs.pdx.edu>
() Thu, 17 Jul 2008 17:16:50 -0700
The basic problem is that we provide no way of easily
constructing, on the user side, a packed list of strings of
known size and count to use in requests. However, part of
the philosophy of XCB is that it won't repack data for the
application: the app is expected to pass parameters in a
format ready to put on the wire. This is a feature for
performance-concerned apps that keep the data lying around
in the proper format, but it's not so much a feature for
figuring out what's going on.
Sounds good, at the C level.
Thus, in a few cases such as SetFontPath, we currently just
punt and ask for a char* and a length. This is clearly a
bug, but we haven't heard a better suggestion. Probably the
best we can do is just provide the function everybody wants
in util/aux. Better suggestions are gratefully accepted.
Thanks for the explanation. I suggest you keep the C bindings of the
protocol spec (and their specific performance-related assumptions,
such as this case) separate from the encoding of the X Protocol in
XML. This way, the encodings can be more useful on their own apart
from the C bindings (an original design goal, IIUC, and one that i
fully support).
Practically, this means extending the patch to include the workaround
plus explanation (such as the one written above) in the code (python,
now?) that generates the C bindings, preserving continuity for users
of the C bindings.
I realize this is more work and that people are itching to get a
release out, so i won't object if such a combined patch is accepted
later. (It will take me some time to grok the C bindings generation
code, anyway.)
thi
More information about the Xcb
mailing list