|
da5caabb
|
2025-06-16T15:45:42
|
|
Add RMLVO builder API
Before this commit, the API to work with RMLVO was quite minimal: it
only uses raw strings from the `xkb_rule_names` struct. However:
- it forces the users to deal with error-prone string formatting;
- it does not enforce tying together layouts and variants;
- it limits adding new features by requiring defining delimiter
characters and the corresponding parsing.
Added the following API:
- `xkb_rmlvo_builder_new()`
- `xkb_rmlvo_builder_append_layout()`
- `xkb_rmlvo_builder_append_option()`
- `xkb_rmlvo_builder_unref()`
There is no intermediate `layout` nor `option` object, in order to
to keep the API simple. The only foreseen extension is enabling
configuring layout-specific options.
|
|
|
1a10f858
|
2025-05-06T18:05:06
|
|
Add xkb_keymap_new_from_names2
This is just `xkb_keymap_new_from_names()` with an explicit keymap
format.
|
|
|
551cca2a
|
2024-12-03T10:12:03
|
|
state: Add server API for updating latched and locked mods & layout
Up to now, the “server state” `xkb_state` API only offered one entry
point to update the server state – `xkb_state_update_key`, which reflects
the direct keyboard keys state. But some updates come out-of-band from
keyboard input events stream, for example, a GUI layout switcher.
The X11 XKB protocol has a request which allows for such updates,
`XkbLatchLockState`[^1], but xkbcommon does not have similar
functionality. So server applications ended up using
`xkb_state_update_state` for this, but that’s a function intended for
client applications, not servers.
Add support for updating the latched & locked state of the mods and
layout. Note that the depressed states cannot be updated in this way --
XKB does not expect them to be updated out of band.
[^1]: https://www.x.org/releases/X11R7.7/doc/kbproto/xkbproto.html#Querying_and_Changing_Keyboard_State
Fixes: #310
Signed-off-by: Ran Benita <ran@unusedvar.com>
Co-authored-by: Ran Benita <ran@unusedvar.com>
Co-authored-by: Pierre Le Marre <dev@wismill.eu>
|
|
|
7cd1180b
|
2025-05-06T11:07:47
|
|
modifiers: Add xkb_keymap_mod_get_mask()
Added a dedicated API to query modifier masks rather than relying on
a hack using `xkb_state_update_mask` and `xkb_state_serialize_mods`.
Furthermore, this hack may not work in the future if we remove virtual
mods resolution in `xkb_state_update_mask` to avoid corner-cases issues.
|
|
|
dd642359
|
2025-05-07T00:06:10
|
|
Bump version to 1.9.2
|
|
|
8e92f25e
|
2025-03-13T21:26:59
|
|
rules: Added xkb_components_names_from_rules()
This is mainly for debugging purposes and to enable displaying KcCGST
values from RMLVO resolution in `xkbcli compile-keymap --kccgst`.
|
|
a1770132
|
2023-09-25T11:41:48
|
|
Compose: add iterator API
Allow users to iterate the entries in a compose table. This is useful
for other projects which want programmable access to the sequences,
without having to write their own parser.
- New API:
- `xkb_compose_table_entry_sequence`;
- `xkb_compose_table_entry_keysym`;
- `xkb_compose_table_entry_utf8`;
- `xkb_compose_table_iterator_new`;
- `xkb_compose_table_iterator_free`;
- `xkb_compose_table_iterator_next`.
- Add tests in `test/compose.c`.
- Add benchmark for compose traversal.
- `tools/compose.c`:
- Print entries instead of just validating them.
- Add `--file` option.
- TODO: make this tool part of the xkbcli commands.
Co-authored-by: Pierre Le Marre <dev@wismill.eu>
Co-authored-by: Ran Benita <ran@unusedvar.com>
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
e4226011
|
2023-05-04T11:55:51
|
|
Use consistent indentation for map and CSS files
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
12f99d0d
|
2020-09-05T22:57:42
|
|
Bump version to 1.0.0
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
d92a248c
|
2020-02-05T17:42:06
|
|
API to query modifier set required to type a keysym
The new API is useful to implement features like auto-type and
desktop automation. Since the inputs for these features is usually
specified in terms of the symbols that need to be typed, the
implementation needs to be able to invert the keycode->keysym
transformation and produce a sequence of keycodes that can be used
to type the requested character(s).
|
|
|
0345aba0
|
2020-02-12T23:44:42
|
|
Support translation Unicode codepoints to keysyms
In order to support features like auto-type and UI automation, the
relevant tools need to be able to invert the keycode->keysym->text
transformation. In order to facilitate that, a new API was added.
It allows querying the keysyms that correspond to particular Unicode
codepoints. For all practical purposes, it can be thought of as an
inverse of xkb_keysym_to_utf32().
|
|
18d6aebe
|
2017-12-11T22:41:55
|
|
keysym: add xkb_keysym_to_{lower,upper} to public API
These can be useful in some odd cases.
There is already an implementation (+ tests) for internal use, so all
that's needed is to export them.
If xkbcommon were to provide a way to convert a Unicode codepoint to a
keysym, this could have been implemented externally as follows:
uint32_t codepoint = xkb_keysym_to_utf32(keysym);
uint32_t upper_codepoint = my_unicode_library_to_upper(codepoint);
xkb_keysym_t upper_keysym = theoretical_xkb_keysym_from_utf32(upper_codepoint);
However keysym -> codepoint is not injective so such a function is not
possible strictly speaking.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
a0a41332
|
2016-02-27T19:06:14
|
|
state: allow different modes for calculating consumed modifiers
The current functions dealing with consumed modifiers use the
traditional XKB definition of consumed modifiers (see description in the
added documentation). However, for several users of the library (e.g.
GTK) this definition is unsuitable or too eager. This is exacerbated by
some less-than-ideal xkeyboard-config type definitions (CTRL+ALT seems
to cause most grief...).
So, because we
- want to enable alternative interpretations, but
- don't want to expose too much internal details, and
- want to keep things simple for all library users,
we add a high-level "mode" parameter which selects the desired
interpretation. New ones can be added as long as they make some sense.
All of the old consumed-modifiers functions keep using the traditional
("XKB") mode. I mark xkb_state_mod_mask_remove_consumed() and as
deprecated without adding a *2 variant because I don't it is very useful
(or used) in practice.
Alternative modes are added in subsequent commits (this commit only adds
a mode for the existing behavior).
https://github.com/xkbcommon/libxkbcommon/issues/17
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
1c6d21b4
|
2016-03-13T20:42:39
|
|
Add symbol versions forgotten in 0ce17ef3ea3722c1cfe7af3
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
b92f7924
|
2014-10-18T16:38:13
|
|
Change initial symbol file versions to V_0.5.0
It will be quite confusing to use V_0.4.3 since this was already
released without symbol versioning.
Hopefully this doesn't cause any trouble for people who are using -git.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
edc98b54
|
2014-09-12T18:44:30
|
|
compose: add xkbcommon-compose - implementation
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
1ba7d9ec
|
2014-09-19T12:35:52
|
|
doc: reorder "Keymap Components" functions
Put the general keymap stuff before key-specific functions.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
5444f6a8
|
2014-09-09T19:08:46
|
|
build: use symbol versioning
Symbol versions provide a means by which ELF utilities can determine
whether a program is incompatible with a too-old library version so
that package management tools can autodetect version-based
dependencies and suggest upgrade paths.
[ran: swap xkbcommon.map and xkbcommon-x11.map]
Signed-off-by: Jan Engelhardt <jengelh@inai.de>
Signed-off-by: Ran Benita <ran234@gmail.com>
|