kc3-lang/libxkbcommon/test/rulescomp.c

Branch :

Log

Author Commit Date CI Message
ef88c7ef 2012-04-03 15:14:16 Rename xkb_desc to xkb_keymap struct xkb_desc was just a hangover from the old XkbDescRec, which isn't a very descriptive name. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
9b14e0c3 2012-03-29 17:38:44 Tests: Release context on failure to build keymap No practical effect since they exit(1) regardless, but it keeps valgrind happy. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
034ffce6 2012-03-27 17:22:35 Use xkb_contexts in keymap compilation Primarily for the include path, but also for the logging in future. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
d3908b63 2012-03-24 12:33:28 Define our own None atom value Since we define our own xkb_atom_t type, it makes sense not to use the X11/X.h None value. This way we can also remove a lot of X11 includes. Signed-off-by: Ran Benita <ran234@gmail.com>
d22b8dbb 2012-03-23 22:25:47 Move utils.{c,h} to be used by the entire project This is a first step for making consistent use of utils.h also outside of xkbcomp/ . Signed-off-by: Ran Benita <ran234@gmail.com>
d039622a 2012-03-22 17:39:12 Rename keymap allocation API Signed-off-by: Daniel Stone <daniel@fooishbar.org>
3077e97e 2012-02-15 16:37:31 tests: Free returned XKB map Signed-off-by: Daniel Stone <daniel@fooishbar.org>
ead9d0cb 2012-02-15 11:49:10 Move include path from X11/extensions/ to xkbcommon/ Signed-off-by: Daniel Stone <daniel@fooishbar.org>
97fbc348 2010-07-02 12:14:03 Rename XkbRMLVOSet to struct xkb_rule_names
5669e1a8 2010-07-02 11:43:56 Compile with -fvisibility=hidden when possible
3f0034a9 2010-07-02 11:50:01 Rename public entry points to lowercase and underscore
9f602686 2010-07-01 14:35:24 Pull in enough structs and defines from XKBstr.h to only need XKB.h We want to move away from sharing implementation structs and let libX11 and libxkbcommon use each their own set of structs.
d95b2893 2010-06-30 17:13:21 Make XkbcInitAtoms() call optional
2c4a045a 2010-06-21 14:22:26 Allow external atom databases Allow people to plug in an external atom database (e.g. the X server's), so we don't have to migrate our own atoms over later. We are a bit over-keen on atoms at the moment, so it does pollute the atom database a bit though. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
e98eb805 2009-04-09 20:52:26 test: Remove extraneous includes These programs don't actually use the internal API.
babae389 2009-04-08 17:54:55 Change CompileKeymapFromRules to take XkbRMLVOSet Let's use a nice interface now that it's available from XKBrulescommon.h.
6a84a34d 2009-04-08 07:46:25 Remove all non-public API from XKBcommon.h header The noble intention was to expose all the new API and new generic types in the split out kbproto headers through XKBcommon.h. It turns out that would be a massive amount of work in the server. Someday, but first just wedging in XkbCompileKeymap* would be good. Most of the API is in new internal xkb*.h headers. In order to allow the XKBcommon.h header to be used from the server, we can't pull in other headers from kbproto since the server has its own copies. However, types that are different (XkbDescRec, XkbAction) still have Xkbc equivalents here, and I think they should be used in the server.
95dbbb8a 2009-04-04 09:37:53 rulescomp: Remove unneeded API
5cc55d7c 2009-04-04 09:14:20 Test compiler to simulate xkbcomp usage Added a test program, rulescomp, which takes a RMLVO set and generates a XkbcDescPtr. This is essentially what the xserver will do, except that we still need to access some xkbcomp internal API to make it work.