After positive feedback from several people, we have decided to remove the XID
wrapper structures that attempted to provide C type safety, and replace them
with uint32_t typedefs. Feedback has indicated that these type-safety hacks
generated more trouble than help.
We will bump the libxcb soname at the next release.
We don't want to have to change the libxcb soname if we later manage to remove
the Xlib compatibility functions, and nothing except Xlib should ever use
them, so split them into a separate library.
Rename API to follow a new naming convention:
* XCB_CONSTANTS_UPPERCASE_WITH_UNDERSCORES
* xcb_functions_lowercase_with_underscores
* xcb_types_lowercase_with_underscores_and_suffix_t
* expand all abbreviations like "req", "rep", and "iter"
Word boundaries for the names in the protocol descriptions fall:
* Wherever the protocol descriptions already have an underscore
* Between a lowercase letter and a subsequent uppercase letter
* Before the last uppercase letter in a string of uppercase letters followed
by a lowercase letter (such as in LSBFirst between LSB and First)
* Before and after a string of digits (with exceptions for sized types like
xcb_char2b_t and xcb_glx_float32_t to match the stdint.h convention)
Also fix up some particular naming issues:
* Rename shape_op and shape_kind to drop the "shape_" prefix, since otherwise
these types end up as xcb_shape_shape_{op,kind}_t.
* Remove leading underscores from enums in the GLX protocol description,
previously needed to ensure a word separator, but now redundant.
This renaming breaks code written for the previous API naming convention. The
scripts in XCB's tools directory will convert code written for the old API to
use the new API; they work well enough that we used them to convert the
non-program-generated code in XCB, and when run on the old program-generated
code, they almost exactly reproduce the new program-generated code (modulo
whitespace and bugs in the old code generator).
Authors: Vincent Torri, Thomas Hunger, Josh Triplett
The big change is treating numbers as separate "words" in the
translation, which leads to funny-looking names like xcb_char_2_b_t, but
makes more sense than the alternative in other situations and was
suggested on the mailing list.
This version still disagrees with Vincent's last proposed XSL, but I
think my output is now preferable. Hopefully Josh has been thinking
along the same lines.