[Xcb] Your GSOC proposal: "Complete input support for XCB"

[Peter Harris]

On 2010-04-09 07:01, Christoph Reimann wrote:
>> The technical side is likely to be fairly straight-forward (if you like
>> python).
> 
> I looked at the XML bindings Mariusz did last year, it appears to me
> that there are 5 new elements:
> enumref, switch, unop, sumof, popcount.
> So for all remaining elements the C language binding is fixed anyway
> by the current generator code. From what I understood so far, mapping
> of enumref, unop, sumof and popcount should be straight forward in C
> as Mariusz designed these with explicit C bindings in mind if I quote
> the mailing list correctly.

Yes, <switch> is the tricky one.

>> The hard part is figuring out what the generated C API ought to
>> look like when you're done updating the generator.
> 
> This is still not perfectly clear to me - if the mapping of the new
> elements would be straight forward, the C API generated from those
> should be as well (?).

Yes. But you (correctly) left <switch> off your list of "straight forward".

> Before submitting a proposal I would like to understand what the time
> determining steps would be (in another mailing list post -
> http://www.mail-archive.com/xorg@lists.freedesktop.org/msg10998.html -
> you stated that only the language binding would probably be enough for
> one GSoC project - I guess you don't mean the autogenerated binding here?).

No, I do mean autogenerated binding.

Getting the accessors to work correctly for replies with <switch> is a
fairly straight-forward technical problem.

Getting requests with <switch> in them defined properly is a social
problem. Right now, the only thing even remotely similar is
<valueparam>. So we can take that as an example. Do we want to just
accept a blob for the switch and make the caller responsible for filling
out the blob properly? Do we want to do something more like xcb-util
does (a giant structure, and make libxcb responsible for scatter/gather
out of it)? Do we want to do something else entirely?

And what happens when <switch> is nested? Upon closer inspection, there
don't appear to be any requests with nested <switch>, only replies.
That'll simplify things somewhat.

So you need to get users of libxcb involved in a discussion, present
some prototypes, hash out use cases, etc.

> At the moment I would suggest
> - completing the keyboard related stuff for the core protocol first
> (ie implement the missing functions like XLookupString) first
> - then generate the C language bindings from xkb.xml
> - extend the keyboard related functions in xcb/util with XKB
> functionality (ie do what Xlib does).

All three of those is aggressive for a single GSoC project, but I like
the way each one stands alone and will be useful even if you run out of
time.

By the time you get the first piece done, you'll be one of the "users of
libxcb" mentioned above, and have a better idea of how to handle
<switch> in an xcb-ish way. Doubly so if you've been looking ahead to
the 3rd piece, so you know how you'd want to use the generated xkb
functions.

So I approve of this plan.

Peter Harris
-- 
               Open Text Connectivity Solutions Group
Peter Harris                    http://connectivity.opentext.com/
Research and Development        Phone: +1 905 762 6001
pharris at opentext.com            Toll Free: 1 877 359 4866