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