xkbcommon/xkbcommon.h


Log

Author Commit Date CI Message
Daniel Stone bf194080 2012-09-19T16:19:57 Promote keymap enumeration API to public Rename the functions to get keysyms by key/layout/level to fit with the recent public API renames, and expose them. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 33a66515 2012-09-12T19:55:06 API change: Rename xkb_map_* and group -> layout Move xkb_map_* functions to xkb_keymap_*, xkb_key_* functions under either xkb_keymap or xkb_state, and rename groups to layout in all user-visible API. Backwards-compatible hooks are provided, such that old source will build, but silently mangled to the new names, and old binaries will also continue to work. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 80e15681 2012-09-12T19:52:30 Add xkbcommon-compat.h and compat.c So we can start renaming stuff while retaining backwards source and binary compatibility. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
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 b4b40d73 2012-09-12T16:54:07 Copyright updates With Dan Nicholson's permission (via email), update his copyright and license statements to the standard X.Org boilerplate MIT license, as both myself and Ran have been using. Clean up my copyright declarations (in some cases to correct ownership), and add copyright/license statements from myself and/or Ran where appropriate. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Pekka Paalanen 517c7ed7 2012-08-20T15:34:07 xkbcommon.h build fix for missing stdarg.h In file included from external/collabora/libxkbcommon/src/xkb-priv.h:87, from external/collabora/libxkbcommon/src/xkbcomp/xkbcomp.h:30, from external/collabora/libxkbcommon/src/xkbcomp/xkbcomp-priv.h:30, from external/collabora/libxkbcommon/src/xkbcomp/action.h:30, from external/collabora/libxkbcommon/src/xkbcomp/action.c:27: external/collabora/libxkbcommon/xkbcommon/xkbcommon.h:279: error: expected declaration specifiers or '...' before 'va_list' Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Daniel Stone e60e9523 2012-09-11T12:35:24 kbproto unentanglement: XkbExplicit*Mask Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita 8d7d9792 2012-08-28T00:42:59 log: replace "priority" by "level" everywhere Now that we don't use syslog, "level" does sound more commonplace. We should change it while there is still nobody using it. Also leave some space between the integers of the xkb_log_level enum values, if we ever need to shove more in between. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 06d7803a 2012-08-30T12:13:37 state: fix mod_names_are_active This function was always returning -1. Adding a test, we see that test/state.c treat the is_active functions as returning booleans, which would treat -1 as success, so we test for > 0 instead (most users would probably get this wrong as well...). Also update the documentation for the are_active functions, and add a ATTR_NULL_SENTINEL for gcc __attribute__((sentinel)). Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone 2f1f1bca 2012-08-08T14:26:23 Add xkb_map_mod_mask_remove_consumed A fairly simple helper which, given an xkb_mod_mask_t, removes all modifiers which are consumed during processing of a particular key. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 5e276adb 2012-08-08T14:01:46 Add xkb_log_level enum rather than using syslog Instead of relying on people including syslog.h, add our own XKB_LOG_LEVEL_* defines. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita 1a930bf2 2012-08-07T00:20:40 Add API to query whether a modifier is consumed Currently the user has no way of knowing which of the active modifiers have been used in the translation of a keycode to its keysyms. The use case is described in the GTK docs: say there's a menu accelerator activated by "<Alt>+". Some layouts have "+" shifted, and some have it on the first level. So in keymaps where "+" is shifted, the Shift modifier is consumed and must be ignored when the user is testing for "<Alt>+". Otherwise, we may get "<Alt><Shift>+" and the accelerator should not actually fire. For this we also use the preserve[] information in the key types, which can forces us to report modifiers as unconsumed even if they were used in the translation. Until now we didn't do anything with this information. The API tries to match its surronding. It's not very efficient but this can be fixed. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita f2ecd665 2012-08-06T20:04:22 log: allow to resore default log function Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 70f35cfb 2012-07-20T13:10:13 Add logging API Add new public API to provide the library users with some options to control and customize the logging output from the library. It is based upon the skeleton from the libabc demo libray: https://git.kernel.org/?p=linux/kernel/git/kay/libabc.git which is public domain and works pretty well. This requires passing in the context object in every logging call, and thus the conversion is done file by file. We also remove the global warningLevel variable in favor of a verbosity level in the context, which can be set by the user and is silent by default. One issue is the ACTION calls, which, while nice, do not play very well with line- and priority-based logging, and would require some line continuation handling or keeping state or some other compromise. So instead remove these and just inline them with their respective warning/error. So instead of: ERROR("Memory allocation failed\n") ACTION("Removing all files on hardisk\n") its something like that: log_err("Memory allocation failed; Removing all files on harddisk\n") Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 5e164ff1 2012-07-23T00:41:27 build: drop the include/ directory The include/ dir is somewhat redundant and makes it just a bit harder to handle the -I directives from out side of automake; without it the default $(top_buildir) just works. Here's also some further justifications I found: http://smcv.pseudorandom.co.uk/2008/09/pc-uninstalled/ Signed-off-by: Ran Benita <ran234@gmail.com>