[Xcb] GSoC 2009: XKB and XI2 support

[Josh Triplett]

On Wed, Sep 16, 2009 at 10:18:19AM +0200, Mariusz Ceier wrote:
> Josh Triplett pisze:
> > On Tue, Sep 15, 2009 at 11:55:16AM +0200, Mariusz Ceier wrote:
> >> Julien Danjou pisze:
> >>> As you may know, Marius Ceier has been a Google sponsored student
> >>> working on XCB this summer.
> >>>
> >>> He wrote XML files describing XKB and XI2 protocol. He also had to do
> >>> XKB2, but since the spec were not finished in time, he was not able to
> >>> do that. AFAIK, he also touched some other part needed to make XKB and
> >>> XI2 work, mostly the Python C code generator.
> > 
> > Sounds very awesome; we definitely need to support those extensions, and
> > they've proven quite hard in the past.
> > 
> >>    I would need some RFC on new tags that I introduced for XKB, from the
> >> point of view of code generators of different languages.
> >> Now I will describe these tags here briefly:
> >>  - enumref - it's a reference to already declared enum item e.g.
> >>    <enumref ref="Const">MaxLegalKeyCode</enumref>
> > 
> > The concept of an enumref seems fine.  What does the "ref" attribute
> > mean?
> "ref" is the reference to the enum type/name, and MaxLegalKeyCode in the
> example means item name to reference.

Ah, OK.  Makes sense.

> >>  - if - conditional inclusion of fields, based on expression, it always
> >> is the last field of struct, e.g.
> >>    <if name="ifHasPreserve">
> >>        <!-- expression -->
> >>        <fieldref>hasPreserve</fieldref>
> >>        <!-- fields for inclusion -->
> >>        <list > ...
> > 
> > Nice!
> > 
> > Using the first child of the if as the conditional expression seems
> > quirky, but preferable to requiring an extra tag around the conditional
> > expression.
> > 
> > Why does the if need a name?
> > 
> I was thinking how it could be implemented in C, and I have come to the
> conclusion that I would need some name, also in the standard these
> conditional fields have names.

Giving the fields names makes sense; I just don't know that it makes
sense to name the if rather than the fields themselves.

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

> >>      - bitcase - include all that matches, in the example above, when
> >> 'case' is renamed to 'bitcase', x and y fields would be included in
> >> struct. I used this a lot.
> > 
> > Sounds fairly reasonable, given the common approach of using flags to
> > specify items.  In fact, it could potentially replace <valueparam> in
> > some cases.
> > 
> > Checking that it has the obvious semantics: the fields inside a given
> > <case> get included if
> > (top-level bitcase expression value) & (case expression value) == (case expression value)
> > ?
> > 
> Fields in <bitcase> are included if ( (switch expression) & ( expression
> in bitcase ) == ( expression in bitcase ) )
> <case> and <bitcase> both are in <switch>, and they distinguish between
> two variants of <switch>, for <case> fields in <case> are included if (
> (switch expression ) == (case expression ) )

Got it.  Makes sense to me.  (I got confused and thought <switch>
changed to <bitcase> and then still contained <case>s, rather than
<case> changing to <bitcase> inside a <switch>.  Your approach seems
much more sensible.)

> >>  - 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 '~'.

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

- Josh Triplett