src/text.c


Log

Author Commit Date CI Message
Daniel Stone ae7856db 2017-06-26T21:38:52 text: NULL-terminate SI mask names The list should have a NULL sentry. Add one. testcase: 'interpret KP_Delete+AnyOfOrNaneo(ll)' Signed-off-by: Daniel Stone <daniels@collabora.com>
Peter Hutterer 9045b035 2018-07-23T11:17:17 text: init the target buffer to zero There's a (theoretical?) path where we might end up strcpy() buf without ever writing to it. This happens if the mask is nonzero but specifies a modifier larger than the one in the xkb_mod_set. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Ran Benita 787faf36 2014-04-22T12:23:36 keymap: don't use darray in xkb_mod_set Instead just statically allocate the mods array (of size MAX_MOD_SIZE = 32). The limit is not going anywhere, and static allocations are nicer (nicer code, no OOM, etc.). It's also small and dense enough. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 6b1cdee1 2014-04-22T11:47:23 keymap: add and use xkb_mods_{foreach,enumerate}() To iterate over an xkb_mod_set. Slightly nicer interface and makes transitioning from darray easier. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita edc0aef5 2013-02-08T13:21:27 text: take xkb_mod_set instead of the entire keymap The modifier printing functions only need the modifier information, they don't care about keys or leds, etc. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita ca3170ad 2013-02-08T13:09:33 Add struct xkb_mod_set The only thing that the compilation phase needs the keymap for currently is for access to the modifier information (it also modifies it in place!). We want to only pass along the neccessary information, to make it more tractable and testable, so instead of passing the entire keymap we add a new 'mod_set' object and pass a (const) reference to that. The new object is just the old array of 'struct xkb_mod'. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 51a1df2f 2014-04-19T15:56:27 keymap: move ModNameToIndex from text.c and use it in keymap.c Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 769b91c5 2014-02-08T15:30:05 Use (1u << idx) instead of (1 << idx) where appropriate It doesn't matter (I think), since the implicit conversion doesn't have any effect (e.g. sign-extension). But it's better to be aware of the type. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita e91d2653 2013-08-01T23:09:46 scanner: allow empty key name literals Some keymaps actually have this, like the quartz.xkb which is tested. We need to support these. https://bugs.freedesktop.org/show_bug.cgi?id=67654 Reported-By: Gatis Paeglis <gatis.paeglis@digia.com> Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita be38862b 2013-07-26T00:50:26 keymap: remove struct xkb_key_redirect_action The file src/xkbcomp/action.c already doesn't handle this action type and fails if it encounters it. So lets not pretend to do something with it, and ignore it rather than failing. If we/someone wants this we can consider implementing it. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita d1eae42a 2013-03-01T21:31:08 text: some style changes Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 4e8dcca8 2013-03-01T18:33:40 text: clean up and fix the *MaskText functions The snprintf trick that LedStateText and ControlMaskText do cannot work, because you can't use the buffer as an argument to write to itself! (posix at least has 'restrict' there). So those two actually never worked for more than one value (i.e. with a +). Fix that, and do the same cleanup to ModMaskText. Now we have 3 functions which look exactly the same, oh well. Also increase the context text buffer size, you never know. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 8cee7490 2013-02-17T22:18:57 Change 'indicator' to 'led' everywhere possible The code currently uses the two names interchangeably. Settle on 'led', because it is shorter, more recognizable, and what we use in our API (though of course the parser still uses 'indicator'). In camel case we make it 'Led'. We change 'xkb_indicator_map' to just 'xkb_led' and the variables of this type are 'led'. This mimics 'xkb_key' and 'key'. IndicatorNameInfo and LEDInfo are changed to 'LedNameInfo' and 'LedInfo', and the variables are 'ledi' (like 'keyi' etc.). This is instead of 'ii' and 'im'. This might make a few places a bit confusing, but less than before I think. It's also shorter. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 998c957a 2012-10-30T18:21:56 action: don't allow private actions with a known type Some obscure bug having to do with Private actions; see the comments. This was prompted by: https://bugs.freedesktop.org/show_bug.cgi?id=56491 Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 6a94b122 2012-10-22T20:49:44 Split the mods, layout, leds parts of xkb_state_components Note first: This commits breaks the ABI somewhat. If an application is run against this commit without recompiling against the updated header, these break: - xkb_state_layout_*_is_active always retuns false. - xkb_state_serialize_mods always returns 0. So it might break layout switching in some applications. However, xkbcommon-compat.h provides the necessary fixes, so recompiling should work (though updating the application is even better). Split the enum to its individual components, which enables us to refer to them individually. We will use that later for reporting which components of the state have changed after update. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita bb82759c 2012-10-18T23:08:10 Move _text() functions from keymap-dump to text.c And make them use context_get_buffer() instead of using a static char array. This was the last non-thread-safe piece we had, as far as I can tell. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita e6946ae2 2012-10-18T22:55:17 Remove a couple more uses of static char buffers Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 714e95e1 2012-10-18T22:51:10 Contextualize GetBuffer() Instead storing the buffer in a non-thread-safe static array, we move it to the context. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita eb748ab6 2012-10-18T21:04:27 Clean up xkb_sym_interpret a bit First we split the LEVEL_ONE_ONLY bit off of the 'match' field, which allows us to turn enum xkb_match_operation to a simple enum and remove the need for MATCH_OP_MASK. Next we rename 'act' to 'action', because we've settled on that everywhere else. Finally, SIMatchText is changed to not handle illegal values - it shouldn't get any. This removes one usage of the GetBuffer hack. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 6d74e66e 2012-10-06T17:53:53 Replace 0xff with MOD_REAL_MASK_ALL To make it easier to see where it's used. The name is just to match MOD_REAL. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 39232e6d 2012-10-06T17:21:09 Remove now-unneeded mod type annotations Most of the mod type annotations can now be changed to MOD_BOTH, because if you pass a mask which can only contain real mods in the first place to e.g. ModMaskText, then MOD_REAL and MOD_BOTH will give the same result. In the cases where MOD_BOTH is only ever the argument, we just remove it. What's left is where it really "matters". Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 9ebd2f67 2012-10-06T14:34:17 text: explicitly take mod_type in mod functions This essentially "tags" each invocation of the functions with the modifier type of the argument, which allows for easy grepping for them (with the aim being, to remove anything but MOD_BOTH). Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 6d580127 2012-10-06T14:15:06 text: share code for modifiers Add static common functions which take enum mod_type, and change the existing ones to use them. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 424de613 2012-10-05T22:46:21 Keep real and virtual mods in the same table in the keymap We change the keymap->vmods array into keymap->mods, and change it's member type from struct xkb_vmod to struct xkb_mod. This table now includes the real modifiers in the first 8 places. To distinguish between them, we add an enum mod_type to struct xkb_mod. Besides being a more reasonable approach, this enables us to share some code later, remove XKB_NUM_CORE_MODS (though the 0xff mask still appears in a few places), and prepares us to flat out remove the distinction in the future. This commit just does the conversion. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 1005b320 2012-10-05T22:07:04 Don't use shifted virtual modifier masks Modifier masks can be confusing in some places. For example, key->vmodmap only contains virtual modifiers, where the first is in position 0, the second in 1 etc., while normally in a xkb_mod_mask_t the virtual modifiers start from the 8th (XKB_NUM_CORE_MODS) position. This happens in some other places as well. Change all of the masks to be in the usual real+virtual format, and when we need to access e.g. keymap->vmods we just adjust by XKB_NUM_CORE_MODS. (This also goes for indexes, e.g. interpret->virtual_modifier). This makes this stuff easier to reason about. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita dd29b14e 2012-10-03T12:57:53 Remove the XKB_NUM_VIRTUAL_MODIFIERS limit Turn the virtual modifiers arrays in the keymap to a single darray, which doesn't use this limit. The number of virtual modifiers is still limited by the size of xkb_mod_mask_t, so we make sure not to go over that. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 3b389b15 2012-09-27T18:49:13 Don't limit key names to 4 characters Currently you can't give a key in xkb_keycodes a name of more than XKB_KEY_NAME_LENGTH (= 4) chars. This is a pretty annoying and arbitrary limitation; it leads to names such as <RTSH>, <COMP>, <PRSC>, <KPAD> etc. which may be hard to decipher, and makes it impossible to give more standard names (e.g. from linux/input.h) to keycodes. The purpose of this, as far as I can tell, was to save memory and to allow encoding a key name directly to a 32 bit value (unsigned long it was). We remove this limitation by just storing the names as atoms; this lifts the limit, allows for easy comparison like the unsigned long thing, and doesn't use more memory than previous solution. It also relieves us from doing all of the annoying conversions to/from long. This has a large diffstat only because KeyNameText, which is used a lot, now needs to take the context in order to resolve the atom. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita bbaa11c6 2012-09-21T14:58:31 Rename map.{c,h} to keymap.{c,h} Seeing as we don't like "map" anymore. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita b2110705 2012-09-16T14:45:32 Organize src/ and test/ headers - Add context.h and move context-related functions from xkb-priv.h to it. - Move xkb_context definition back to context.c. - Add keysym.h and move keysym upper/lower/keypad from xkb-priv.h to it. - Rename xkb-priv.h to map.h since it only contains keymap-related definitions and declarations now. - Remove unnecessary includes and some and some other small cleanups. Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone a8d462e3 2012-09-11T12:28:29 kbproto unentanglement: XkbSI match flags Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone ed9fd5be 2012-09-11T12:20:21 kbproto unentanglement: control actions Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 830fe671 2012-09-10T20:07:54 kbproto unentanglement: XkbIM_* Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 0b2506db 2012-09-10T19:23:16 kbproto unentanglement: action types Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 314965b1 2012-08-21T14:40:51 Remove deprecated actions We didn't do anything with ISO_Lock, ActionMessage, RedirectKey, and the device-specifying variants of the pointer actions, so remove those. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone b04d896a 2012-08-21T12:48:20 kbproto unentanglement: XkbNumVirtualMods Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone f5dffd2b 2012-08-21T11:21:19 kbproto untanglement: XkbKeyNameLength Define it ourselves as XKB_KEY_NAME_LENGTH and use that, instead of the one from XKB.h. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita af2a8b3a 2012-09-02T21:45:42 Unify some string tables from xkbcomp, text and keymap-dump We move the LookupEntry struct from expr.h to text.h, along with most of the lookup tables. This makes them available everywhere. Looking up a value in the LookupEntry format is slower than direct index mapping, but it allows multiple names per value (with the canonical one being first) and "all"- and "none"-type masks. These functions are not used anywhere efficiency matters. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 7ae0c6ba 2012-08-31T19:26:51 Convert rest of names in xkb_keymap back to atoms These were kept as atoms, but since the keymap was exposed in the API, we converted them to strings; no the keymap is no longer exposed, so we can go back to atoms. They make the keymap smaller (at least on 64-bit machines) and the comparisons faster. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 41472822 2012-08-29T15:17:00 Use XKB_MOD_INVALID instead of XkbNoModifier Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 591df115 2012-08-27T19:20:41 Move enum xkb_file_type to xkbcomp/ast.h This is a more suitable place for this enum, since it's internal to xkbcomp. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita efc2d741 2012-08-27T18:58:36 xkbcomp: clean up compile_keymap function We make the xkb_file_type enum sequential instead of masks, and then we don't have to repeat the file types several times in the function. Makes the code cleaner. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 07b18bde 2012-08-09T02:33:51 Modernize struct xkb_mods Currently xkb_mods has the following members: - uint8_t real_mods - 8 X11 core mods - xkb_mod_mask_t vmods - 16 virtual mods, zero-based index - xkb_mod_mask_t mask - the computed effective *real* modifier mask, basically a cache for the first two which is: real_mods | real mods computed from vmods Our API acts on masks which combine the real_mods and vmods into a single value, which is: 8 first bits real mods | 16 next bits virtual mods (XkbNumModifiers = 8, XkbNumVirtualMods = 16). This is also the format which ResolveVModMask uses (which is where all the modifier masks really "come from", e.g. "Shift+Lock+Level5" -> xkb_mod_mask_t). What the code does now after getting the mask from ResolveVModMask, is to break it into real part and virtual part and store them seperately, and then join them back together when the effective mask is calculated. This is all pretty useless work. We change xkb_mods to the following: - xkb_mod_mask_t mods - usually what ResolveVModMask returns - xkb_mod_mask_t mask - the computed mask cache And try to consistently use the word "mods" for the original, non-effective mods and mask for the effective mods (which can only contain real mods for now, because things break otherwise). The separation is also made clearer. The effective masks are computed by UpdateModifiersFromCompat after all the sections have been compiled; before this the mask field is never touched; after this (i.e. map.c and state.c) the original mods field is never touched. This single execption to this rule is keymap-dump.c: it needs to print out only the original modifiers, not computed ones. This is also the reason why we actually keep two fields instead keeping one and modifying it in place. The next logical step is probably to turn the real mods into vmods themselves, and get rid of the distinction entirely (in a compatible way). Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 4c00278c 2012-08-02T01:09:41 Remove xproto build dependency Very little left to do for this. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 7c7e4341 2012-08-01T11:25:34 Use only one set of core mod name-to-index functions These were repeated 5 times. Note that this changes the ABI slightly: XKB_MOD_NAME_CAPS is changed from "Caps Lock" to "Lock", which is the ordinary legacy mod name for it. Since its hidden behind a #define, it's best to stay compatible with the old names (as I think was intended, given that "Mod1", etc. are the same). Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 9617b092 2012-08-05T12:03:51 filecomp: fix path and error message Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita b2c4331a 2012-07-28T22:15:59 Handle key names consistently We treat the key names as fixed length, non NUL terminated strings of length XkbKeyNameLength, and use the appropriate *Text functions to print them. We also use strncpy everywhere instead of memcpy to copy the names, because it does some NUL padding and we might as well. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 80ab9f12 2012-08-02T23:40:31 keymap-dump: use ActionTypeText Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 4f843c81 2012-07-24T13:24:59 Drop Xkbc prefix of text functions Not really needed and inconsistent. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 6cb98200 2012-07-24T13:15:40 Use xkb_mod_mask_t and xkb_mask_index_t throughout Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 1313af8f 2012-07-15T01:31:34 Get rid of xkb_key_names Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone 9308a460 2012-07-17T10:20:15 Run source tree through uncrustify .uncrustify.cfg committed for future reference also, but had to manually fix up a few things: it really likes justifying struct initialisers. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita 1f492901 2012-07-11T18:00:31 Enlarge keysym name buffers and mention in comment The longest keysym is 27 chars long. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 48b4d30a 2012-06-29T17:05:33 Use enum for file types enums are nice for some type safety and readability. This one also removes the distinction between file type mask / file type index and some naming consistency. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 5e59ef3f 2012-05-09T17:54:37 Remove support for xkb_layout and xkb_semantics file types These are two aggregate file types which are not used anywhere. We maintain useful-enough backward compatibility in the parser, by treating them as xkb_keymap. The keymap type allows for all types of components, so they will still compile fine if they ever come up. Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone 38cb6390 2012-05-09T15:15:30 Change all 'xkb' xkb_keymap names to 'keymap' To make it a bit more clear what it actually is. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone e1af48bc 2012-05-09T13:22:34 Rename keysym <-> string API Change them to refer to the string representation of the keysym's name as a name rather than a string, since we want to add API to get the Unicode printable representation as well. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita b610b2b9 2012-05-08T14:52:23 Rename XKBcommonint.h to xkb-priv.h and use it Make the files in the src/* directory use their own header or a consilidated private header. This makes the file dependencies clearer. Also drop the pointless "xkb" file name prefix, add split a few declarations to their own files (atom.h and text.h). Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 62a75dc1 2012-04-10T23:08:49 Remove unused stuff from XKBcommonint.h Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita a641a185 2012-04-06T03:38:55 Use stdbool.h 'Cause defining your own True and False is so 1990's. Signed-off-by: Ran Benita <ran234@gmail.com> [daniels: Fixed for xkb_desc -> xkb_keymap changes.]
Ran Benita 8fbd44fd 2012-04-06T03:12:50 Implicitly include config.h in all files The definitions in config.h should be available in all files an implementation detail; it can be included through the build system instead of having each file pull it every time. This is especially helpful with AC_USE_SYSTEM_EXTENSIONS, as _GNU_SOURCE and friends can have an effect by merely being defined, which can lead to some confusion if its effective for only half the files. And we don't really support a build _without_ config.h; so, one less thing to worry about. Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone ef88c7ef 2012-04-03T15: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>
Ran Benita 2165e16e 2012-03-24T02:36:11 Fix all -Wsign-compare warnings i.e comparison of signed and unsigned values. These are mostly harmless but fixing them allows to compile cleanly with -Wextra. Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone 0bb24c2d 2012-03-09T19:03:59 Introduce xkb_keysym_t type Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 731e5c40 2012-03-09T18:53:47 Stringify public name types Ensure that all names under xkb_desc are strings, rather than atoms. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone ed5c6c17 2012-03-09T16:26:34 Remove geometry support, again It still parses geometry, but happily throws it away. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita f3e4335f 2012-02-24T16:07:17 Fix all constness warnings These are all trivial/obvious fixes which clear a bunch of warnings. Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone ead9d0cb 2012-02-15T11:49:10 Move include path from X11/extensions/ to xkbcommon/ Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Kristian Høgsberg e8798287 2010-10-08T15:33:18 Don't return a static buffer in public API
Adam Jackson 73ca959d 2010-09-27T16:05:52 Dead code removal and static markup Signed-off-by: Adam Jackson <ajax@redhat.com>
Kristian Høgsberg be2bd661 2010-08-25T14:51:52 Pull in a few #defines from libxkbfile and lower kbproto requirement
Kristian Høgsberg 3f0034a9 2010-07-02T11:50:01 Rename public entry points to lowercase and underscore
Kristian Høgsberg 9f602686 2010-07-01T14: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.
Kristian Høgsberg e10e16ad 2010-06-30T17:20:56 Constify XkbcAtomText() Atoms aren't mutable and this lets us put tbGetBuffer() back in the box.
Kristian Høgsberg 0ece2cdb 2010-06-30T16:56:24 Drop more malloc/free wrappers
Kristian Høgsberg 47d3b396 2010-06-28T06:50:12 Drop CARD32 and Opaque types
Daniel Stone 60e7eeeb 2010-06-17T03:16:09 Use CARD32 instead of Atom, drag in XkbClientMapRec On 64-bit architectures, XID varies in size between the server (always 32 bits), and non-server (always unsigned long) for some inexplicable reason. Use CARD32 instead to avoid this horrible trap. This involves dragging in XkbClientMapRec so we don't get stuck in the KeySym trap. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone a0e180b0 2010-06-15T16:42:06 Expose tbGetBuffer to the rest of libxkbcommon This will let us implement XkbAtomGetString on top of XkbAtomText, instead of having the latter get a duplicated string, dump it into a temporary buffer, and subsequently free it (sigh). Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 48baabeb 2010-06-15T19:30:30 Atoms: Avoid allocations in XkbAtomText() XkbAtomGetString() returns a freshly-allocated string, whereas XkbAtomText() returns the same in a temporary buffer. XkbAtomText used to call XkbAtomGetString() and then free the result, which seems quite spectacularly pointless when you think about it. Shuffle the atom code around so we don't have to allocate for XkbAtomText(). This changes semantics slightly wrt non-printable characters, but I haven't been able to see any effect so far. And it may well be ever so slightly quicker. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 62eb167d 2009-04-25T14:51:46 XKB: Text: Use keysym <-> string conversion from keysym.c Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Dan Nicholson 6a84a34d 2009-04-08T07: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.
Dan Nicholson a53b9b1e 2009-03-28T15:32:51 Add XkbModIndexText replacement Now, I think we should have all the *Text functions we need.
Dan Nicholson 54aea7fe 2009-03-28T15:12:30 Add VMod Text functions from xkbfile
Dan Nicholson 2671b777 2009-03-28T14:06:26 Add more *Text functions from xkbfile This should cover all the usage in xkbcomp. The format arguments were dropped except for the special case of XkbModMaskText, which needs to write in XkbCFile format in HandleVModDef. This was just changed to a Bool to avoid the need for the macros in XKBfile.h. The function prefixes have been renamed to be unique from xkbfile.
Dan Nicholson 72df9bb3 2009-03-28T06:32:08 Move *Text APIs into libxkbcommon These seem like they might be generally useful, and more will be needed from xkbfile.