kc3-lang/libxkbcommon/src/keymap.c

Branch :

Log

Author Commit Date CI Message
60bd9202 2012-11-11 00:22:46 keymap: wrap the layout parameter if it is out of range for the key The functions num_levels_for_key() and get_syms_by_level() have a 'layout' parameter. Currently it is expected that this value is always legal for the key, as determined by num_layouts_for_key(). However, there are legitimate use cases for passing an out-of-range layout there, most probably passing the effective layout, and expecting to get the keysyms/levels for just this layout. So we wrap it just as we do in the xkb_state_* functions. This is also useful for stuff like this: http://developer.gnome.org/gdk/stable/gdk-Keyboard-Handling.html#gdk-keymap-lookup-key If this behavior is not desired, the user has the option to check against num_layouts_for_key herself. https://bugs.freedesktop.org/show_bug.cgi?id=56866 Reported-by: Gatis Paeglis <gatis.paeglis@digia.com> Signed-off-by: Ran Benita <ran234@gmail.com>
f76859bc 2012-10-23 09:58:11 keymap: use plain array for keymap->group_names Again it is not resized. Signed-off-by: Ran Benita <ran234@gmail.com>
3477d9e4 2012-10-05 16:23:03 Finish first round of API documentation There are a few @todo's, but nothing serious. Signed-off-by: Ran Benita <ran234@gmail.com>
bbf388ec 2012-10-11 16:54:17 Make xkb_keymap_num_leds return the index range instead of active count Currently xkb_keymap_num_leds() returns a count of valid (settable) leds. Because the indexes might be non-consecutive, and some leds might not be settable, it is incorrect to use this function for iterating over the leds in the keymap. But this is the main use case of this function, so instead of the current behavior we adapt the function to the use case by making it return the needed range of iteration. The caller needs to handle invalid intermittent indexes, though. Signed-off-by: Ran Benita <ran234@gmail.com>
b6ddd105 2012-10-11 14:05:49 keymap: rename keymap->sym_interpret -> sym_interprets This can be a bit confusing. Signed-off-by: Ran Benita <ran234@gmail.com>
9197eb0f 2012-10-10 19:08:01 Remove the XKB_NUM_INDICATORS limit Use a darray instead of a static array of size 32. We still enforce XKB_MAX_LEDS because of the size of xkb_led_mask_t. Signed-off-by: Ran Benita <ran234@gmail.com>
f3732d83 2012-10-10 17:51:06 keymap: don't use darray for keymap->keys It's never resized. Signed-off-by: Ran Benita <ran234@gmail.com>
2f4db8a9 2012-10-10 09:47:31 keymap, state: don't assume led index < xkb_keymap_num_leds xkb_keymap_num_leds() returns the number of leds that have any possibility of being set. Even if a led is defined but can not be set in any way, it is not counted. In a few places currently we assume that led indexes are smaller than this number, which is wrong both for the above reason and for the fact that the xkb format actually allows explicitly setting the indicator index, which means that the indexes might be non-consecutive. We don't really have good API to iterate on leds, now, because xkb_keymap_num_leds is pretty useless. To work around that we use sizeof(xkb_led_mask_t) * 8. This makes the "Group 2" led work (try switching to a layout other than the first in test/interactive). Signed-off-by: Ran Benita <ran234@gmail.com>
424de613 2012-10-05 22: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>
dd29b14e 2012-10-03 12: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>
5d265926 2012-09-24 14:57:30 keymap: remove some more unneeded macros It clearer to just access the needed data directly. Signed-off-by: Ran Benita <ran234@gmail.com>
c955f8e2 2012-09-24 14:41:09 keymap: store a pointer to the type in xkb_group instead of index Gets rid of some more unneeded indirection, including the XkbKeyType macro. Signed-off-by: Ran Benita <ran234@gmail.com>
01b00d75 2012-09-24 12:11:31 keymap, symbols: improve xkb_key memory layout Add struct xkb_group and xkb_level for use in xkb_key, to mirror how it's done in KeyInfo, GroupInfo, LevelInfo in symbols.c. This corresponds more nicely to the logical data layout (i.e. a key has groups which have levels), and also removes a lot of copying and ugly code due to the index indirections and separate arrays which were used before. This uses more memory in some places (e.g. we alloc an action for every level even if the key doesn't have any) but less in other places (e.g. we no longer have to pad each group to ->width levels). The numbers say we use less overall. Signed-off-by: Ran Benita <ran234@gmail.com>
9a18b872 2012-09-23 17:52:51 Add format argument to xkb_keymap_get_as_string This function really needs a format argument, for symmetry with the keymap creation functions. If we add new formats, we will almost certainly want to add support for serializing it into a string. It would also allow to convert from one format to another, etc. The in the common case, the user would just want to use the format she used to create the keymap; for that we add a special XKB_KEYMAP_USE_ORIGINAL_FORMAT value, which will do that (it is defined to -1 outside of the enum because I have a feeling we might want to use 0 for something else). To support this we need to keep the format inside the keymap. While we're at it we also initialize keymap flags properly. This changes the API, but the old xkb_map_get_as_string name works as expected so this is the best time to do this. Signed-off-by: Ran Benita <ran234@gmail.com>
d941bc0c 2012-09-23 22:12:43 keymap, symbols: use darray for num_groups Instead of using a static array of size XKB_NUM_GROUPS, because we want to get rid of this limit. Signed-off-by: Ran Benita <ran234@gmail.com>
7a90f9e2 2012-09-23 20:36:01 keymap: don't use XKB_NUM_GROUPS for key->kt_index One unneeded XKB_NUM_GROUPS less. Signed-off-by: Ran Benita <ran234@gmail.com>
bbaa11c6 2012-09-21 14: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>