[Xcb] RFC: Altenum updates for xcb/proto

[Barton C Massey]

In message <49A5A073.4090209 at opentext.com> you wrote:
> We could rename xcb_<enumname>_t to xcb_<enumname>_enum or
> similar, but that would break any existing code that
> actually uses the enum types for anything (not that I'm
> aware of any). Or, if we're mucking with enum_t
> definitions, we could just toss them altogether and
> #define the constants (since C chucks enum members into
> the global namespace anyway).

That'd be my vote.  It's only C. :-)  The only upside of
enums that I'm aware of is that the debugger is able to
display them symbolically.

> Alternatively, we could use a different name for the enum.
> XCB_WINDOW_NONE_NONE? XCB_WINDOW_IS_NONE? XCB_WNDW_NONE?
> XCB_NULLABLE_WINDOW_NONE?

Uggh.

> > They can be
> > auto-generated, after all, and sooner or later someone is
> > going to decide that XCB_RANDOMEXTENSIONTYPE_NONE is 17
> > instead of 0 for some reason and we'll have a problem if we
> > don't have them have unique names.
> 
> Unique names for non-zero None are a given, of course.
> XCB_NOTIFY_DETAIL_NONE == 7, to pick the example from xproto.
> XCB_RENDER_SUB_PIXEL_NONE == 5, to pick the extension example. I don't
> think either of those conflict with the global XCB_NONE.

Since some of these need additional naming, I'd like to see
all of them done that way, so that I don't have to know
whether my particular NONE is 0 to guess what its name is.

    Bart