[Xcb] GSoC 2009: XKB and XI2 support

[Mariusz Ceier]

Josh Triplett pisze:
> 
> Giving the fields names makes sense; I just don't know that it makes
> sense to name the if rather than the fields themselves.
> 
Another reason is I assumed that, there can be many switches ( as the
last fields ) in structure in some protocols. If this won't be the case,
I think the name attribute could be dropped.
Now I see that bitcases should have names - for only one iteration over
previous fields of structure, when accessing bitcase vs. accessing
fields of bitcase:
xcb_xkb_[ bitcase name ]_t * xcb_xkb_get_[bitcase name]([struct type]);

>>>>   - bitcount - counts number of bits set or cleared, e.g.
>>>>       <bitcount value="1"> <fieldref>namesPresent</fieldref> </bitcount>
>>> What does the "value" attribute mean here?
>>>
>> it means which bits to count, (expr&(1<<bit)) == (value<<bit)
> 
> Ah.  In that case, how about dropping the value attribute and just
> applying the element to the appropriate value?  Like this:
> 
> <popcount><op op="&amp;"><fieldref>namesPresent</fieldref><value>1</value></op></popcount>
> 
> The resulting C would look like: xcb_popcount(namesPresent & 1).
> 
makes sense to me, I will change xmls.

>>>>  - neg - bit negation, e.g.
>>>>     <neg><fieldref>clear</fieldref></neg>
>>> This should use something like the existing <op> tag, with ~ as the
>>> operator.  (I don't know if <op> works for unary operations, though, so
>>> that needs some thought.)
>>>
>> <op> tag requires two arguments.
> 
> Hmmm, right.
> 
> In any case, could you please call this "complement" or "compl" or
> "bitneg" something like that, rather than "neg"?  "neg", to me, means
> unary '-', not '~'.
> 
ok, I will change the name, to 'compl'.

>>>>  - replyof - makes copy of reply of given request a field of other
>>>> request, e.g.
>>>>     <replyof request="GetMap" name="map" />
>>> Seems fine.  I find it a little unfortunate that we can't just use
>>> <field> to define this, but then what would go in the type attribute?
>> maybe xcb_xkb_get_map_reply_t if it is fixed length.
> 
> Right, except we don't want to make any assumptions about the name of
> the structures after translation from XML.  Different target languages
> or uses may use different naming conventions.
Yes, and I don't know if for other than C generators this tag is feasible.

Mariusz Ceier