[Xcb] xproto test failed

[Peter Harris]

On Tue, Feb 17, 2009 at 8:14 PM, Barton C Massey wrote:
> In message <eaa105840902161846l364e2430l18e8a7e9417915db at mail.gmail.com> you wrote:
>> "altenum" is for types like "WINDOW, but may also contain
>> the magic values None or CopyFromParent", or "ATOM, but
>> may also contain the magic value Any". So on the C side,
>> it needs to be an XID.
>
> Yes. The "natural" C type for the first of these would seem
> to me to be something vaguely like
>
>  typedef union {
>    uint32_t xid;
>    xcb_window_class_t window_class;
>  } xcb_special_window_t;
>
> You would then use an xcb_special_window_t in places like
> xcb_create_window_request() where these special values can
> appear.  This could all be generated from the XML given
> altenum tags in the right places, it seems like?

Ah. Yeah, that would work, assuming xcb_window_class_t also boils down
to a uint32_t. I thought you were suggesting

typedef union {
  xcb_window_t xid;
  enum window_special window_class;
} xcb_special_window_t;

...which wouldn't work portably, since the compiler is free to make
'enum' any size it wants.

> We used to have a more extreme version of this for Drawables
> in XCB, but everybody hated it so we ripped it out.

This is my other objection. That would make the API quite a bit
uglier, even if it doesn't necessarily break the current ABI.

>> Once I finish this pass of annotations (both to xproto and the
>> extensions), my Grand Plan is to start adding type annotations to
>> enums themselves, and attach those enums to <valueparam>s. This would
>> allow us to auto-generate xcb/util/aux's xcb_aux_create_window (and
>> xcb_params_cw_t) and friends if we wanted to. But that's in the rather
>> distant future (unless someone else steps in, of course).
>
> I'm not quite following the mechanism, because I'm slow
> sometimes.  But auto-generating all that xcb_aux* cruft is a
> worthy goal IMHO.

Something like
  <enum name="CW">
    <item name="BackPixmap" type="PIXMAP" altenum="BackPixmap">
<bit>0</bit></item>
...
  <request name="CreateWindow" opcode="1">
...
    <valueparam value-mask-type="CARD32"
                value-mask-name="value_mask"
                value-list-name="value_list"
                enum="CW" />

although I still need to think about <item type=""> vs
<item><type></type></item>. As I said above, this is relatively far in
the future.

Note that annotating the enum with types is not strictly necessary to
generate what we have in xcb/util/aux today. xcb/util/aux currently
punts and uses uint32_t instead of the more descriptive xcb_pixmap_t
and friends, so tagging valueparam with the existing typeless enum
would suffice. But the type annotations would allow for better
pretty-printers (which is what I'm actually interested in. util/aux
cruft auto-generation is just a bonus, from my perspective).

Thanks,
 Peter Harris