[Xcb] RFC: Altenum updates for xcb/proto

[Peter Harris]

On Wed, Feb 25, 2009 at 3:54 AM, Barton C Massey wrote:
> I'm confused what we're trying to name?
>
> The only constraint I have on generated names, that I'm
> pretty religious about, is that any generated name should be
> inferrable from the protocol specification without reference
> to other documentation or source code.  In this case, does
> this mean something like XCB_WINDOW_NONE?

The core of the problem is that, while xcb.h has "XCB_NONE", there is
no way to reference this hard-coded #define from within the XML.

I'd like to avoid creating a whole plethora of new single-entry enums
(XCB_WINDOW_NONE, XCB_PIXMAP_NONE, XCB_COLORMAP_NONE, XCB_CURSOR_NONE,
XCB_ATOM_NONE, XCB_FONT_NONE, and maybe even a few
XCB_extension_newtype_NONE).

All of those xidtypes have instances where they are 'None-able'. I'm
not sure if that would be spelt "Nonable" or "Noneable"; I like the
"Nullable" suggestion by Eyal elsethread. It has the advantage of not
making up a new word (as it is already in use for the same concept
elsewhere).

Just brainstorming: Perhaps a special case in the code generator, to
drop the new enum? I see that generated
XCB_WINDOW_CLASS_COPY_FROM_PARENT already (partially?) duplicates the
hard-coded XCB_COPY_FROM_PARENT (and has since 2006).

Just brainstorming: Maybe a new flag in the xsd to mark none-able
<field>s? Seems messy.

While we're on the subject: The same issue crops up with CurrentTime.
In my private branch, generated XCB_TIME_CURRENT_TIME duplicates the
hard-coded XCB_CURRENT_TIME. Is this acceptable?

Peter Harris