[Xcb] confused about naming

[Barton C Massey]

In message <200706022016.07203.hto at arcor.de> you wrote:
> > > 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).

And should be, IMHO.  I think the missed renaming before is
just a bug.

> 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".

This seems like a bad bug to me also.  I'd be willing to
tolerate another API rev to get rid of it.

> 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 think everything should be named in the new style, even if
this requires further API changes.  I'm bummed that we're
only seeing these now.  My bad, I guess, for not looking
closer earlier.

Thanks much for the notes!

    Bart