From 990bc3f015a4f8fce2eb918375defcd44980a845 Mon Sep 17 00:00:00 2001 From: marha Date: Fri, 8 Jun 2012 09:33:13 +0200 Subject: Used synchronise script to update files --- libxcb/doc/xkb_issues | 74 +++++++++++++++++++++++++-------------------------- 1 file changed, 37 insertions(+), 37 deletions(-) (limited to 'libxcb/doc/xkb_issues') diff --git a/libxcb/doc/xkb_issues b/libxcb/doc/xkb_issues index f10c015e5..80efcc1fc 100644 --- a/libxcb/doc/xkb_issues +++ b/libxcb/doc/xkb_issues @@ -1,38 +1,38 @@ - -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 + +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. \ No newline at end of file -- cgit v1.2.3