kc3-lang/libxkbcommon/changes
Branch :
Log
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
 |
a47961b1 | 2024-10-12 16:43:46 | registry: Restore default libxml2 error handler after parsing Leaving the custom error handler could have resulted in a crash after the context has been freed. Closes: https://github.com/xkbcommon/libxkbcommon/issues/529 | |
 |
b8888345 | 2024-09-20 09:17:23 | tools: Add xkbcli dump-keymap-{wayland,x11} There is currently no easy way to dump a keymap from a Wayland compositor, such as `xkbcomp -xkb $DISPLAY -` could do for X servers. As `xkbcomp` may not be intuitive, a corresponding tool for X servers would also be useful. Add the tools `xkbcli-dump-keymap-{wayland,x11}` by tweaking the existing `xkbcli-interactive-{wayland,x11}` tools. | |
|
b1da948a | 2024-10-08 19:43:18 | symbols: Add doc for multiple actions | |
|
7c4c718b | 2024-09-30 06:13:38 | Allow only the first group in symbols sections when using RMLVO Currently `xkb_keymap_num_layouts` may return a greater number than the number of layouts configured using RMLVO, because we allow symbols sections to define various groups per key. This is unintuitive and kind of buggy: groups should be added via rules by setting an explicit `:n` modifier. Fix: when parsing a keymap using RMLVO resolution: - Get the expected layouts count from the resulting KcCGST. - Drop the groups after the first one in included symbols sections. This will ensure that a symbol section can only define one group per key. Notes: - Compiling a keymap string directly is unaffected. - RMLVO resolution may still produce more groups than the input layouts. Indeed, some legacy rules in xkeyboard-config rely on this to insert automatically a US layout before the given non-Latin one, resulting in two layouts while only one was given. | |
|
948f7a59 | 2024-10-09 08:34:27 | symbols: Skip interprets only for groups with explicit actions Previously setting explicit actions for a group in symbols files made the parser skip compatibility interpretations for the corresponding *whole* key, so the other groups with *no* explicit actions could result broken on some levels. In the following example, `<RALT>` would have an action on group 2, because it is explicit, but none on group 1 because interpretation are also skipped there as a side effect: ```c key <RALT> { symbols[1]= [ ISO_Level3_Shift ], symbols[2]= [ ISO_Level3_Shift ], actions[2]= [ SetMods(modifiers=LevelThree) ] }; ``` Fixed by skipping interpretations *only* for groups with explicit actions. We still set `key->explicit |= EXPLICIT_INTERP` if at least one group has explicit actions. In such case, when dumping a keymap, we will write explicit actions for *all* groups, in order to ensure that X11 and previous versions of libxkbcommon can parse the keymap as intended. One side effect is that no interpretation will be run on this key anymore, so we may have to set some extra fields explicitly: repeat, virtualMods. Thus the previous example would be bumped as: ```c key <RALT> { repeat= No, symbols[1]= [ ISO_Level3_Shift ], actions[1]= [ SetMods(modifiers=LevelThree,clearLocks) ], symbols[2]= [ ISO_Level3_Shift ], actions[2]= [ SetMods(modifiers=LevelThree) ] }; ``` | |
|
1d897502 | 2024-10-04 08:09:28 | keysyms: Update using latest xorgproto xorgproto commit: d7ea44d5f04cc476dee83ef439a847172f7a6bd1 Relevant MR: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/91 | |
|
4ea9d431 | 2023-11-16 17:12:03 | rules: Add support for :all qualifier Some layout options require to be applied to every group to maintain consistency (e.g. a group switcher). Currently this must be done manually for all layout indexes. This is error prone and prevents the increase of the maximum group count. This commit introduces the `:all` qualifier for KcCGST values. When a rule with this qualifier is matched, it will expands the qualified value (and its optional merge mode) for every layout, e.g. `+group(toggle):all` (respectively `|group(toggle)`) would expand to `+group(toggle):1+group(toggle):2` (respectively `|group(toggle):1|group(toggle):2`) if there are 2 layouts, etc. If there is no merge mode, it defaults to *override* `+`, e.g. `x:all` expands to `x:1+x:2+x:3` for 3 layouts. Note that only the qualified *value* is expanded, e.g. `x+y:all` expands to `x+y:1+y:2` for 2 layouts. `:all` can be used in combination with special layout indexes. Since this can lead to an unexpected behaviour, a warning will be raised. | |
|
cdafba4f | 2024-09-24 15:23:16 | rules: Add support for index ranges There is a lot of repetition in the current rules files provided by xkeyboard-config, because the MLVO mappings need to match on the exact layout/variant index. This also prevents to increase the number of maximum groups, because it does not scale. We introduces the following new special layout/variant indexes: - “single”: matches a single layout; same as with no index. - “first”: matches the first layout/variant, no matter how many layouts are in the RMLVO configuration. It allows to merge `layout` and `layout[1]` patterns. - “later”: matches all but the first layout. This is an index range. - “any”: matches layout at any position. This is an index range. We also introduces the new `%i` expansion, which correspond to the index of the matched layout in a mapping with an index range. Example: layout[later] = symbols my_layout = +my_symbols:%i * = +%l[%i]:%i Let’s have a look at concrete examples from xkeyboard-config: ! model layout = symbols * * = pc+%l%(v) ! model layout[1] = symbols * * = pc+%l[1]%(v[1]) ! model layout[2] = symbols * * = +%l[2]%(v[2]) ! model layout[3] = symbols * * = +%l[3]%(v[3]) ! model layout[4] = symbols * * = +%l[4]%(v[4]) ! layout option = symbols * grp:toggle = +group(toggle) ! layout[1] option = symbols * grp:toggle = +group(toggle):1 ! layout[2] option = symbols * grp:toggle = +group(toggle):2 ! layout[3] option = symbols * grp:toggle = +group(toggle):3 ! layout[4] option = symbols * grp:toggle = +group(toggle):4 With this commit we can now simplify it into: ! model layout[first] = symbols * * = pc+%l[%i]%(v[%i]) ! model layout[later] = symbols * * = +%l[%i]%(v[%i]):%i ! layout[any] option = symbols * grp:toggle = +group(toggle):%i The latter rule will work even if we increase XKB_MAX_GROUPS, whereas the former would require to add the missing entries for the new groups. In order to maintain consistent rules, we now disallow layout and variant to have different indexes. For example, the following mapping are now invalid: - layout variant[1] - layout[1] variant[2] - layout[1] variant - layout[first] variant[1] - layout[first] variant - layout variant[any] - etc. | |
|
7697c712 | 2024-09-16 16:09:11 | rules: Resolve relative include statements using XKB paths Contrary to keymap files, the `! include` statement in rules does not lookup include paths added to `xkb_context`. So it is not possible e.g. to import another file in the same folder without using an absolute path. - Added path utils: `is_absolute(path)`. - Added XKB paths lookup to enable e.g. `! include evdev` to work. - Added test. | |
|
0cd1087a | 2024-09-12 01:43:56 | xkbcli how-to-type: Enhance arguments parsing & doc Currently the positional parameter of the CLI is either a Unicode code point or a keysym. However their respective format is not documented. It turns out that there are multiple issues due to the use of `strtol`: - Code points can be parsed as octal, decimal and hexadecimal, while keysyms can only be parsed as hexadecimal. Some programs outputs keysyms in their decimal form (e.g. `wev`) so it is worth to bring symmetry with code points. - Octal format is unusual for both and is triggered by leading zeros, which is unintuitive in this context. - `U+NNNN` format is the standard format for Unicode code points but is not supported. - Plain characters are not supported, e.g.: a, é, ß, Æ, γ, 🦆, etc. Although this is probably the easiest format for most users. Fixed the issues above: - Allow the code point to be passed exactly in the following formats: - Literal character (requires UTF-8 character encoding of the terminal); - Decimal number; - Hexadecimal number: either `0xNNNN` or `U+NNNN` (any digit count) - Allow the keysym to be passed exactly in the following formats: - Decimal number; - Hexadecimal number: `0xNNNN` (any digit count); - Name. - Improve both `--help` message and manual page. | |
|
44df6eee | 2024-09-23 07:27:48 | Add new warnings for deprecated keysyms Add 2 new warnings: - Deprecated keysym name (typo, historical alias, etc.); - Deprecated keysym (all names and forms). Guard deprecated keysym tests with verbosity level ≥2, so they are run only when actually needed. | |
|
e4269202 | 2024-09-20 10:41:00 | keysyms: Fix off-by-one XKB_KEYSYM_NAME_MAX_SIZE The constant did not account for the terminating `NULL` byte and this was sadly not caught by the tests. Fixed the invalid value, the corresponding script and the tests. | |
|
05ba96db | 2024-08-20 16:41:38 | rules: Fix wild card handling The handling of wild card `*` is different in libxkbfile and X server: wild card matches empty strings for model and option but not for layout nor variant, while in libxkbcommon wild cards always match empty strings. See: - https://gitlab.freedesktop.org/xorg/lib/libxkbfile/-/blob/bf985c68acb1244f51ec91414532a2347fbc1c4c/src/maprules.c#L687 - https://gitlab.freedesktop.org/xorg/lib/libxkbfile/-/blob/bf985c68acb1244f51ec91414532a2347fbc1c4c/src/maprules.c#L712 The difference of handling between the components is unfortunately not documented, but we should follow the behavior of the original implementations for consistency. - Fixed by implementing the same behavior than libxkbfile. - Added tests and fixed failing tests. - Improve the documentation of rules to highlight the special behavior. | |
 |
9af1f9f2 | 2024-09-02 14:18:21 | Add XKB_LED_NAME_COMPOSE and XKB_LED_NAME_KANA | |
|
e9bd7de4 | 2024-07-04 16:22:13 | state: Add support for group latch action Surprisingly, the latch group action was not yet implemented. Added tests to ensure we get the tricky bits right. | |
|
e83d08dd | 2024-02-23 17:10:15 | keysyms: Fast and complete case mappings (Unicode 15.1) The current code to handle keysym case mappings is quite complex and slow. It is also incomplete, as it does not cover recent Unicode database. Finally, it does not handle title case correctly. It would be easier if we were to use only a lookup table, but a trivial implementation would lead to a huge array: the cased characters range from `U+0041` to `U+`1F189, i.e. a span of 127 304 elements. Thus we need some tricks to compress the lookup table. We based our work on the post: https://github.com/apankrat/notes/blob/3c551cb028595fd34046c5761fd12d1692576003/fast-case-conversion/README.md The compression algorithm is roughly: 1. Compute the delta between the characters and their mappings. 2. Split the delta array in chunk of a given size. 3. Rearrange the order of the chunks in order to optimize consecutive chunks overlap. 4. Create a data table with the reordered chunks and an index table that maps the original chunk index to its offset in the data table. The compression algorithm is then applied a second time to the previous index table. The complete algorithm optimizes the two chunk sizes in order to get the lowest total data size. The mappings were generated using CPython 3.12.4, PyICU 2.13, PyYaml 6.0.1 and ICU 75.1. Also: - Added explicit list of named keysyms and their case mappings. - Added benchmark for case mappings. - Rework ICU tests. Note: 13b30f4f0dccc08dfea426d73570b913596ed602 introduced a fix for sharp S `U+00DF`. With the new implementation, the *conversion* functions `xkb_keysym_to_{lower,upper}` leave it *unchanged*, while the *predicate* functions `xkb_keysym_is_{lower,upper_or_title}` produce the expected results: ```c xkb_keysym_to_upper(XKB_KEY_ssharp) == XKB_KEY_ssharp; xkb_keysym_to_lower(XKB_KEY_ssharp) == XKB_KEY_ssharp; xkb_keysym_to_lower(XKB_KEY_Ssharp) == XKB_KEY_ssharp; xkb_keysym_is_lower (XKB_KEY_ssharp) == true; xkb_keysym_is_upper_or_title(XKB_KEY_Ssharp) == true; ``` | |
|
addf73c5 | 2024-07-12 09:17:34 | keysyms: Require only 5 bytes for UTF-8 encoding Require only 5 bytes for the buffer of `xkb_keysym_to_utf8`, as UTF-8 encodes code points on up to 4 bytes + 1 byte for the NULL-terminating byte. Previous standard [RFC 2279] (1998) required up to 6 bytes per code point, but has been superseded by [RFC 3629] (2003). [RFC 2279]: https://datatracker.ietf.org/doc/html/rfc2279 [RFC 3629]: https://datatracker.ietf.org/doc/html/rfc3629 | |
|
1d8a25d6 | 2024-07-12 11:10:46 | build: Check for --undefined-version support Gate the use of `--undefined-version` in the linker because it breaks on older GNU `ld`: https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=58272. | |
|
621e3101 | 2024-07-16 07:00:53 | build: Require meson >= 0.58 This will enable f-strings and allow us to simplify the build file. | |
|
737706fe | 2024-03-07 10:08:16 | doc: Use towncrier to handle release notes Towncrier is a utility to produce useful, summarized news files. See: - https://pypi.org/project/towncrier/ - https://towncrier.readthedocs.io Custom configuration for xkbcommon: - New fragments are located in the `changes` directory. - 3 sections: - API: `changes/api` - Tools: `changes/tools` - Build System: `changes/build` - 3 news fragments: - Breaking changes: `.breaking` - New: `.feature` - Fixes: `.bugfix` `NEWS` is renamed to `NEWS.md` because the tool requires `.md` extension to write in markdown format. |