doc/xkb_issues

   1
   2 There are a number of problematic special cases in XKB. The issues
   3 mentioned here are at most partly resolved.
   4
   5 1. The are several XxxDoodad structures defined in xkb.xml. They are used
   6    in a few lists, but in a rather special way:
   7    The struct "CommonDoodad" is supposed to be a rather generic data type,
   8    combining the most basic Doodad fields that are common in all these structures.
   9    All Doodads are encapsulated in a union type simply called "Doodad".
  10    Now this union is used in subsequent list definitions, aiming at a kind of
  11    'polymorphism': From inspection of the protocol and Xlib, the Doodads are to
  12    be discriminated based on their type field.
  13    However the special meaning of the type field is not encoded in the protocol.
  14    Furthermore the TextDoodad and the LogoDoodad are variable size types due to
  15    some fields of type CountedString16, thereby turning the union into a
  16    possibly variable size type as well.
  17    However, for lists with variable size elements, special sizeof functions are
  18    required. These cannot be autogenerated as it cannot be referred which
  19    Doodad type to use for the union.
  20    Therefore, the Doodad type structures are unsupported at the moment.
  21
  22 2. There are still some bugs in xkb.xml: Either certain fields are missing
  23    that are required by the protocol, or Xlib simply has another understanding
  24    of the protocol.
  25
  26 3. The interface for accessors should be reviewed.
  27
  28 4. Currently some bitcases carry 'name' attributes. These could be avoided if
  29    the data within would consist of a singe struct field only.
  30
  31 5. switch could get a 'fixed_size' attribute, so when rewriting valueparam to switch,
  32    an uint32_t * pointer could be used instead of void *.
  33
  34 6. The automatic inclusion of padding requires some complicated coding in the
  35    generator. This is errorprone and could be avoided if all padding is explicitly
  36    given in the protocol definition. For variable size fields that require padding,
  37    the pad tag could get a 'fieldref' attribute. That way padding could be handled
  38    a lot easier in the autogenerator.