RotateProperties has an array of 'atoms' where the spec says 'properties': --- a/src/xproto.xml +++ b/src/xproto.xml @@ -2351,9 +2354,9 @@ authorization from the authors. <request name="RotateProperties" opcode="114"> <pad bytes="1" /> <field type="WINDOW" name="window" /> - <field type="CARD16" name="atoms_len" /> + <field type="CARD16" name="properties_len" /> <field type="INT16" name="delta" /> - <list type="ATOM" name="atoms"> + <list type="ATOM" name="properties"> <fieldref>atoms_len</fieldref> </list> </request>
> --- a/src/xproto.xml > +++ b/src/xproto.xml > @@ -2351,9 +2354,9 @@ authorization from the authors. > <request name="RotateProperties" opcode="114"> > <pad bytes="1" /> > <field type="WINDOW" name="window" /> > - <field type="CARD16" name="atoms_len" /> > + <field type="CARD16" name="properties_len" /> > <field type="INT16" name="delta" /> > - <list type="ATOM" name="atoms"> > + <list type="ATOM" name="properties"> > <fieldref>atoms_len</fieldref> > </list> > </request> > does the name actually matter for anything? the change breaks struct xcb_rotate_properties_request_t API, for no significant gain afaict.
It doesn't gain anything really. I was just comparing some existing code I had to XCB generated code and filed bugs for all the differences that seemed valid. Feel free to close WONTFIX.
On 12/08/11 17:37, Josh Triplett wrote: > On Thu, Dec 08, 2011 at 04:18:23PM -0800, Bart Massey wrote: >> One of the things we do try to enforce is that the names in XCB match >> the names in the spec (where there is one :-) to support just the kind >> of case you describe. On the other hand, I hate to break existing >> code. >> >> Suggestions appreciated; I hate to just let this one die if we could >> figure out something better. > > I can think of one possible solution, if we don't mind using anonymous > union support. Just define the relevant field as an anonymous union, > containing both field names. That would preserve both API and ABI. Unfortunately, anonymous unions are a gcc extension that are not universally supported yet (the next generation ISO C standard, C1X, is supposed to include them, so someday we'll get there).
Closing a WONTFIX since this would break compatibility for no gain.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.