[Xcb] GSoC: final C code mapping for <switch>

Christoph Reimann chrr at arcor.de
Thu Jun 17 14:51:47 PDT 2010

Hi Jamey,
thanks for the fast reply!

> However, to get started, you could implement only the new style API for
> switch, and don't touch existing XML descriptions. Then switching the
> value-params over to switch is a separate project.

The problem I see here is that once the mapping is done, then the
syntax for the request calls is done as well -
I mean the request functions have fixed names like xcb_create_window()
- so in order to have both mappings, one would have to create new
"function names" for basically the same request - one version that
understands the switch type (let's call it xcb_create_window_switch()
for now) and one that understands void *. In order to be backwards
compatible, xcb_create_window() would have to accept void *. Thing is
- I could give requests that need switch some other name right now,
and the value-params can still be converted at some later point. But
if switch now gets the "default request names" and one changes this
naming scheme afterwards, then the request-calls that use switch will
have to be changed in the future.
Ok this is really not clearly formulated, sorry, I'm probable thinking
way too complicated right now, my point is:
I've got the feeling that it could be worth-while to decide on this
issue now - if both variants should be supported, fine with me, but
then the "new style switch" requests need a proper naming.

> By all means, do whatever is easiest while figuring out how to implement
> these extensions--but I'd appreciate it if you'd put the generated
> serialization code back the way it was when you're done.

Got it, will keep that in mind.
As it's getting quite late in Germany - good night!


More information about the Xcb mailing list