[Xcb] confused about naming

[Thomas Hunger]

> > If not, I could change the field names to the new naming
> > convention without breaking the API, because c has only
> > positional parameters: The names themselfes are never referenced
> > [1]. What do you think?
>
> I'm lost now.  What's the proposal here?

Sorry, I compacted this too much. Take e.g.

xcb_randr_set_screen_config_cookie_t
xcb_randr_set_screen_config(xcb_connection_t* c,
                            xcb_drawable_t drawable,
                            xcb_timestamp_t timestamp,
                            xcb_timestamp_t config_timestamp,
                            uint16_t sizeID,
                            int16_t rotation,
                            uint16_t rate);

Here "sizeID" could be written as "size_id" without breaking the API 
(Just for the looks). OTOH I saw that the name-converter is not 
applied to names in event structs. E.g.:

typedef struct xcb_randr_notify_event_t {
    uint8_t                 response_type;
    uint8_t                 subCode;
    uint16_t                sequence;
    xcb_randr_notify_data_t u;
} xcb_randr_notify_event_t;

But "subCode" is part of the API, so this cannot be changed 
to "sub_code".

In my opinion the generator should leave the "name" part of fields and 
lists alone. In the current API it is mixed, so I reproduce the mixed 
case. We could add additional functions which leave the "name" part 
alone though. E.g.

<list type="BYTE" name="data2"/>

would generate

xcb_glx_vendor_private_with_reply_data_2 (in current API)
xcb_glx_vendor_private_with_reply_data2 (in addition to current API)

> I don't think the names of the pad fields in the structs are
> part of the API.  That said, I don't see why it would be
> difficult to number the pads the same way they were before?
> It certainly makes them easier to understand...
Ok, I will do that. It was just laziness.

Tom