[Xcb] bind from XML (was: Objective-C binding)

[Florent Monnier]

Hi,
>   Get via CVS as explained on the xcb DevelopersGuide page,
> or install the individual xproto tarball (latest version is 7.0.5) from
> http://xorg.freedesktop.org/releases/individual/proto/

OK, thanks a lot, I will check this.

> > And I would like to know where is the X protocol specs I should use?
> > Is it this one:  http://www.ietf.org/rfc/rfc1013.txt  ?
>
> They claim that is out of date. The source documents are in

are in what?
Isn't there an X consortium (like the W3 consortium), which produces the specs 
of each X protocol version ? (X11R6, X11R7...?)


> > For exemple OCaml is very strict with types, so I have noticed in RFC
> > in  SECTION 12.  EVENTS  for KeyPress there is:
> >            root, event: WINDOW
> >            child: WINDOW or None
> > while in  ./xcb-proto-0.9/src/xproto.xml  there is:
> >   <event name="KeyPress" number="2">
> >       <field type="WINDOW" name="root" />
> >       <field type="WINDOW" name="event" />
> >       <field type="WINDOW" name="child" />
> >       <!--  [...]  -->
> >   </event>
> >
> > I am not sure at all of this but perhaps it should be a little bit
> > more strict
> > for OCaml users, for exemple switching to:
> >       <field type="WINDOW option" name="child" />
>
> I think this is a very fine idea!
 
Yes! Thanks a lot to Barton :)

> I think in general fields must be described by two attributes:
>
> 1) size in bytes (1, 2, 4) [possibly optional except for enumerations]

Do you really mean bytes?
What happens if the client is made for 8bits bytes, and the host X server 
works with 16bits bytes ?

> 2) allowed types
>
> The types must be allowed to be multiple, since fields can be:
>
> a) simple (CARD32, INT16, BOOL, etc.)
> b) an enumeration (a named <enum>, such as EventMask)
> c) derived (WINDOW == id == CARD32)
not an issue, just specify the derivation with a tag

> as well as a combination of some of the above:
>
> d) a combination of derived types (drawable, which means WINDOW or
> PIXMAP)
> e) a combination of enumerations (ButtonMask or KeyMask)
> f) a derived type or None  (WINDOW or None, depth or CopyFromParent)
> g) a derived type or an enumeration
> h) different types depending on the value of a *different* field
> (Events and Errors are like this)
>
> I'm not sure which XML constructs can best describe all these kinds
> of types.
Perhaps XML is not the best formating for describing the X protocol, but XML 
is easy to parse since there are parser in all languages for XML.

>           Possibly:
>
>   <field type="WINDOW" type2="None" name="child" />
>
> or a compound type entity:
>
>   <typeunion name="WINDOWorNone" size="4">
>      <type>WINDOW</type>
>      <type>None</type>
>   </typeunion>
>   <field type="WINDOWorNone" name="child" />

From my point of view (perhaps I'm wrong) the second one is better,
except I find attributes more easy to parse than PCData both from SAX or DOM,
so this would give:
  <type_alternative name="WINDOWorNone" size="4">
      <type name="WINDOW" />
      <type name="None" />
  </type_alternative>

And for C programmers maybe the tag name "typeunion" could be confusing 
(moreover a tag name "union" exists yet). What do you think of 
"type_alternative" ? (or a shorter one "typealt")

> Currently, there are lots of protocol descriptions that could use
> information about the
> enumerations or exceptions that are allowed for their fields.
>
> The other type hole is in value lists.  They consist of CARD/INT32s,
> but the
> meaning of each item in the list is dependent on the bits set in the
> mask.  Xlib hides
> value lists behind structures, so the individual fields are typed,
> but the raw lists
> are exposed in XCB.

Just like the type WINDOWorNONE, why not a CARDorINT32 ?


-- 
Best Regards
florent