[Xcb] [Xcb-commit] src

[Jamey Sharp]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I was all set to accept the commit that adds XCB_BAD_FOO as a synonym
for XCB_FOO, in the case of X errors, when I noticed that 8 extensions
already have "Bad" in their error names. Apparently "BadWindow" wasn't a
sufficient rebuke for GLX, as with the patch we learned that it was
actually a BAD BAD WINDOW. (no biscuit!)

I'm quite sad that we released libxcb with these extensions having "Bad"
in their error names, as that means that we have structures like
xcb_glx_bad_window_error_t. The "bad" and "error" in that name are
redundant.

GLX is in even worse shape, because one of its errors does not have
"Bad" in its name, while all the others do. Aieee!

For a future release, we should remove "Bad" from all XML descriptions,
and provide deprecated backwards-compatibility typedefs for the
*_bad_*_error_t types. It seems clear to me that protocol specifications
with names like "GlxBadWindow" (as GLX 1.4 specifies it) were written
with the intent that "GlxBad" is not part of the name, but part of the
namespace.

I'm not opposed to namespacing the error constants, either with
"BAD_FOO" for consistency with Xlib, or "FOO_ERROR" for consistency with
the corresponding structure types, or perhaps "ERROR_FOO". A prefix,
like BAD_FOO or ERROR_FOO, would be more consistent with C namespacing
conventions. But whichever convention we like, we need the underlying
names cleaned up before that's feasible.

Meanwhile, I'm going to release libxcb 1.1 without the patch that
automatically prefixes BAD_ onto error names.

Jamey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHLoslp1aplQ4I9mURAnR9AJ9ip8RwjmNowpILCajnUbgOad7wlACfWhqm
EbHT+HxQ7mY81LLNGP9KCMk=
=Rm5R
-----END PGP SIGNATURE-----