[Xcb] XKB once again

[Thomas Hunger]

Hello, 

I have started to translate the XKB extension into XML and hit a few 
spots for which I'd like to hear other opinions. For reference, see 
also
http://lists.freedesktop.org/archives/xcb/2006-November/002465.html

1) Optional Fields:
   As written in the above thread, optional fields can be implemented
   by multiplying with an boolean value:
    
    <op op="*"> 
      <fieldref>preserve</fieldref>
      <fieldref>nXXX</fieldref>
    </op>
 
   This expects that xTrue == 1 and xFalse == 0. These values did not
   change for ages, so I believe this is secure?

2) Passing item lists
   XKB has the notion of item lists. Depending on some bit mask one or
   more items are send or retrieved for each bit. A simple example is
   "XkbSelectEvents". Whenever a bit is set, two fields need to be
   filled by the user.

   I currently use this hack in XML:

    <!-- xxx encode "ref" in op-notation??? -->
    <itemlist name="details"
              ref="(affectWhich&(~clear)&(~selectAll))">
      <option flag="XkbNewKeyboardNotify">
	<field type="SETofKB_NKNDETAIL" name="affectNewKeyboard" />
	<field type="SETofKB_NKNDETAIL" name="newKeyboardDetails" />
      </option>
      <option flag="XkbStateNotify">
	<field type="SETofKB_STATEPART" name="affectState" />
	<field type="SETofKB_STATEPART" name="stateDetails" />
      </option>

   The question is: How would this look like in c? I thought we could
   just let the user submit all fields and ignore the ones not needed
   for transmission.

   xkb_select_events([other arguments],
                     set_of_nkndetail affect_new_keyboard,
                     set_of_nkndetail new_keyboard_details,
                     set_of_statepart affect_state,
                     [...])
 
   In the implementation we would need a pointer which is incremented:

   if (affectWhich&(~clear)&(~selectAll) == XKB_NEW_KEYBOARD_NOTIFY) {
     data_position += XCB_TYPE_PAD(set_of_nkndetail, data_position);
     (*(set_of_nkndetail*)data_position) = affect_new_keyboard;
     data_position += sizeof(set_of_nkndetail);
   }
  
   I am a little out of form concerning c, so the above pointer
   arithmetic may be off?

   I have not investigated yet where XKB requires a TYPE_PAD, but it
   looks like "everywhere".

3) Getting item lists
   Item lists can be passed in replies as well. The difficulty here is
   XkbGetNames. It uses not only optional lists (which could be
   encoded with a zero length) but also optional fields:

   <itemlist name="valueList" ref="which">
	<option flag="XkbKeycodesName">
	  <field type="ATOM" name="keycodesName" />
	</option>
	<option flag="XkbGeometryName">
	  <field type="ATOM" name="geometryName" />
	</option>
        [...]

   This means that in c we cannot just place these fields in a struct,
   because some may be missing. It would be possible to use a getter
   api, like 

     xcb_get_names_reply_get_keycodes_name(xcb_get_names_reply_t* r);

   This function could then calculate the correct byte position.
   Alternatively we could introduce pointers in the reply
   (use "xcb_atom_t* keycodes_name" instead of 
   "xcb_atom_t keycodes_name" to encode the position in the stream).

4) <popcount>
   As already written in the reference mail a <popcount> operator is 
   needed.

I hid my questions really well in the above text, so here the summary:

a) What should the c api look like for passing lists of items?
b) Is xTrue = 1 and xFalse = 0 a given?
c) What should the API look like for fields in lists of items?
d) Does anyone mind introducing the <itemlist>/<popcount>-tags? 

Tom