kc3-lang/libxkbcommon
Branch :
Log
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
 |
28ea23d2 | 2025-08-10 19:41:12 | doc: Update wayland-devel links The mailing list has been migrated to Mailman 3. | |
|
0f9cefb1 | 2025-07-15 12:35:34 | Bump version to 1.11.0 | |
|
3ffb7e73 | 2025-07-16 19:43:27 | doc: Add text format sections to release notes | |
|
eb8697e2 | 2025-07-23 15:21:39 | doc: Clarify keymap format use in protocols | |
|
9cdf3af0 | 2025-08-08 19:31:33 | doc: Miscellaneous enhancements - Fix minor tag typos - Add more links to the README | |
|
13ae4a26 | 2025-08-06 20:07:16 | tools: Add Compose support to how-to-type - Enable Compose support by default; disable it with `--disable-compose` - Some filters are used to avoid combinatorial explosion | |
|
b5d969dd | 2025-08-06 17:22:38 | compose: Move constants to dedicated header | |
|
7394a3c7 | 2025-08-06 20:47:07 | tools: Fix how-to-type modifier mask test | |
|
39726cac | 2025-08-06 20:29:26 | Add xkb_keymap_mod_get_mask2() Retrospectively, `xkb_keymap_mod_get_mask()` should have used a modifier index rather that a modifier name in its type. Since we already published a version with this API, it’s too late to change that, so instead add a new function `xkb_keymap_mod_get_mask2()`. | |
|
055c5362 | 2025-08-06 14:09:35 | tools: Do not use a window for dump-keymap-wayland Previously a window would appear for a very short time, which is unpleasant and potentially dangerous for people sensitive to flashes. | |
|
6df45124 | 2025-08-05 10:19:48 | tools: Add --keymap to xkbcli-how-to-type It enables to load the keymap from a file or stdin instead of resolving RMLVO names. Piping is also interesting for using with `dump-keymap-*` tools. | |
|
09e93fa0 | 2025-08-06 10:12:39 | tools: Enable custom keymap with interactive-{x11,wayland} Added the `--keymap` option to enable providing the keymap to use instead of the one from the display server. Implies `--local-state`. Note that the other RMLVO options do not need to be implemented, since one can simply pipe a keymap from `xkbcli compile-keymap`. The `--keymap` option is also useful for users that do not have the input permissions to access evdev API. | |
|
0aa54741 | 2025-08-04 22:46:36 | tools: Add --local-state for interactive-{x11,wayland} Enable to use a *local* state machine and ignore server updates for modifiers/groups. Only key press/release and new keymap events are used. | |
|
885f8129 | 2025-08-05 23:17:29 | tools: Fix memory leak in interactive-wayland | |
|
9cc19e4e | 2025-08-04 22:42:34 | tools: Fix missing --verbose doc + misc | |
|
9d4885df | 2025-08-04 14:31:13 | tools: Improve how-to-type keysym parsing - Fixed incorrect numeric keysym parsing due to `errno` not being reset. - Added parsing keysym as fallback when `--keysym` is omitted. - Added arguments tests. - Fixed tools test Python types. - Updated documentation. | |
|
5f6f44c9 | 2025-08-04 14:31:26 | test: Add missing tools arguments checks | |
|
29579ad4 | 2025-08-04 12:35:25 | tools: Add --verbose to all tools Added `--verbose` to: - `xkbcli interactive-wayland` - `xkbcli interactive-x11` - `xkbcli compile-compose` - `xkbcli how-to-type` | |
|
6fac73f3 | 2025-08-02 09:49:44 | log: Fix NULL string Fixed regression introduced in 05d13d5f41d94c7776456d856fccb5969e8f5b0a. | |
|
1e0c5790 | 2025-07-23 12:09:32 | keysyms: Fix XF86MediaSelectAuxiliary typo | |
|
f5d079f5 | 2025-08-04 09:58:42 | tools: Improve interactive events output Improved the output of events for `xkbcli interactive-*` tools: - Added `--multiline` to enable multiline event output, which provides more details and does not have formatting limitations. - Added `--uniline` to enable uniline event output. While this is the current default, future versions may switch to multiline display. | |
|
cce63b90 | 2025-08-04 09:48:32 | tools: Print interactive state changes `xkbcli interactive-*` tools: print detailed state change events. | |
|
d8caabf5 | 2025-08-04 09:30:48 | tools: Print interactive key release event `xkbcli interactive-*` tools: - Print key release events. This is particularly useful when analyzing the output sent by another person, in order to know the exact key sequence. | |
|
e9fd95a5 | 2025-07-23 10:01:45 | keysyms: Update using latest xorgproto xorgproto commit: 7fc33fe6d9cf0abc9b62ee976e5cb7ddcd050d1f Relevant MR: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/93 | |
|
a83a482c | 2025-07-18 11:27:52 | tools: Add variants with automatic session type detection Added: - `xkbcli-interactive` - `xkbcli-dump-keymap` | |
|
d60b3213 | 2025-07-16 08:00:30 | Make the ref counting invariants explicit with assertions | |
|
93818226 | 2025-07-15 11:34:06 | Add xkb_rmlvo_builder_ref() | |
|
dc63e5f8 | 2025-07-07 12:28:24 | Ensure config.h is always included first While `config.h` may not be necessary in every file, it ensures consistency and makes code refactoring safer. | |
|
9600981a | 2025-07-01 15:54:09 | bench: Add --keymap to compile-keymap `--keymap` enables using a keymap file rather than resolving RMLVO. | |
|
b21a58d0 | 2025-07-01 14:52:11 | Add support for all level indices to LevelN constants Note that serialization must use numbers instead of names for levels > 8, to ensure backward compatibility. | |
|
e73d1a4d | 2025-07-01 13:05:44 | Add support for all layout indices to GroupN constants This commit enables to use the pattern `Group<INDEX>` for any valid group index `<INDEX>`. Note that the original code in xkbcomp allows constants up to `Group8`, but then will fail if the resulting group is > 4. There does not seem to be any use case for this for such “feature”; it seems rather to be a relic from times were the 4-groups limit was not hopelessly fixed in X. So for consistency in our code base, starting with this commit we now disallow `Group5`..`Group8` for keymap format v1, since it is limited to 4 groups. Also fixed a regression in the serialization of group action, when the group is relative. | |
|
64b1b9d7 | 2025-07-01 13:03:59 | utils: Optimize istreq_prefix | |
|
84914512 | 2025-07-01 18:37:22 | chore: Rename indexes to indices Before this commit there was a mix between the two forms. While “indexes” is correct, “indices” is more usual and also the historical form used in this project. | |
|
58373807 | 2025-06-27 18:21:19 | keysym: Do not convert UTF-32 to deprecated keysyms Before this commit, some code points could be converted to deprecated keysym. This is incorrect, because the relevant keysyms are all deprecated because their mapping to Unicode is uncertain! Ensure that `xkb_utf32_to_keysym()` never returns deprecated keysyms, because there is either another non-deprecated keysym or in last resort we always have the correct keysym available in the Unicode keysym range. | |
|
05d13d5f | 2025-06-26 16:58:50 | include: Fix infinite loop Fixed including an absolute path with no default map triggering an infinite loop. | |
|
1de49d16 | 2025-06-25 17:04:46 | doc: Fix headers markup - Fixed a lot of broken internal links. - Improved the markup of code items. - Fixed a few typos. | |
|
447b7739 | 2025-06-22 10:27:31 | test: Add examples for breaking latches using VoidAction() Consider the following use cases: 1. If `Caps_Lock` is on the second level of some key, and `Shift` is latched, pressing the key locks `Caps` while also breaking the `Shift` latch, ensuring that the next character is properly uppercase. 2. On the German E1 layout, `ISO_Level5_Latch` is on the third level of `<AC04>`. So if a level 3 latch is used to access it, the level 5 must break the previous level 3 latch, else both latches would be active: the effective level would be 7 instead of the intended 5. Both uses cases can be implemented using existing features: - multiple actions per level; - `VoidAction()`: to break latches. | |
|
c4f4ba41 | 2025-06-23 18:15:18 | state: Fix modifier and group latch Prior to this commit, the sequences: - 1. latch A ↓ 2. latch B ↓ 3. latch B ↑ 4. latch A ↑ - 1. latch A ↓ 2. latch B ↓ 3. latch A ↑ 4. latch B ↑ would result in only B being latched, because the XKB protocol specifies that latches are triggered only if keys are *sequentially* tapped, i.e. a strict sequence of press and release of each key. It seems an unnecessary limitation: - `SlowKeys` and `XkbAX_TwoKeys` are the proper accessibility features to control accidental key presses, not latches nor `StickyKeys`. - Latches are also used outside their original accessibility role. A user may activate multiple latch keys simultaneously: - same hand: two latch keys being close to each other; - different hand: two keys being activated independently. Changed the latching behavior so that the rules used to break a latch are the same than those used to prevent it. Depressing and releasing two latching keys simultaneously will now activate both latches, as expected. Since this is a breaking change, it is enabled only by the keymap format `XKB_KEYMAP_FORMAT_TEXT_V2`. | |
|
3d00222e | 2025-06-21 18:26:34 | keymap: Add option `unlockOnPress` for LatchMods() It mirrors the feature of `SetMods()`, so that `StickyKeys` can be implemented. | |
|
d192b3b6 | 2025-06-19 21:57:46 | keymap: Add option `unlockOnPress` for SetMods() It enables e.g. to deactivate `CapsLock` *on press* rather than on release, as in other platforms such as Windows. It fixes a [18-year old issue] inherited from the X11 ecosystem, by extending the [XKB protocol key actions]. As it is incompatible with X11, this feature is available only using the keymap text format v2. [18-year old issue]: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/74 [XKB protocol key actions]: https://www.x.org/releases/current/doc/kbproto/xkbproto.html#Key_Actions | |
|
ee87f6ed | 2025-06-21 19:28:53 | state: Fix broken latch not honoring clearLocks=no Before this commit, breaking a latch (modifier & group) would always clear locks, even if `clearLocks=no`. | |
|
94d8e341 | 2025-06-21 13:17:16 | state: Fix LatchMods mutation to SetMods or LockMods Previously we use inlined version of the corresponding filter functions of the `SetMods()` and `LockMods()` actions, but they were incomplete and did not set some fields (`priv`, `refcnt`) properly. Also, it is error-prone: it requires discipline to keep it in sync. E.g. before this commit, converting to `LockMods()` would always try to unlock `CapsLock` due to the wrong value of the `priv` field. Fixed by using the corresponding filter functions directly, so that we always mutate the filter properly, as in `xkb_filter_group_latch_func`. | |
 |
7a7a3b38 | 2024-02-14 09:47:15 | keymap: Canonically map unmapped virtual modifiers Traditionally, *virtual* modifiers were merely name aliases for *real* modifiers (X *core* modifiers), e.g. `NumLock` was usually mapped to `Mod2` (see `modifier_map` statement). Virtual modifiers that were never mapped to a real ones had no effect on the keymap state. xkbcommon already supports the concept of “pure” virtual modifiers, i.e. virtual modifiers that are *encoded* using the full 32-bit range, not just the first 8 bits corresponding to the real modifiers. But until this commit, one had to declare such mapping *explicitly*: e.g. `virtual_modifiers M = 0x100;`. This has at least two drawbacks: - Numerical values may look quite arbitrary and are not user-friendly. It’s OK in the resulting compiled keymap, but it requires careful sync between sections when developing KcCGST files. - If the modifier is *also* mapped *implicitly* using the traditional `vmodmap`/`modifier_map`, then both mappings are OR-combined. This patch enables to automatically map unmapped virtual modifiers to their *canonical* mapping, i.e. themselves: their corresponding virtual and real modifier masks are identical: `1u << mod_index`. Since this feature is incompatible with X11, this is guarded by requiring at least keymap text format **v2**. Note that for now, canonical virtual modifiers cannot be used in an interpret action’s `AnyOf()`. An interpret action for a canonical virtual modifier must be `AnyOfOrNone()` to take effect: virtual_modifiers APureMod, …; interpret a+AnyOfOrNone(all) { virtualModifier= APureMod; action= SetMods(modifiers=APureMod); }; The above adds a virtual modifier `APureMod` for keysym `a`. It will be canonical iff it is not mapped implicitly. | |
|
d351abee | 2025-06-19 11:24:44 | test: Use explicit keymap format for test_compile_file() | |
|
56a32cc8 | 2025-06-18 11:37:19 | xkbcli-interactive-wayland: xdg-decoration-unstable-v1 Use if available, to get window decoration. Also resize the window bigger enough to make its title readable. | |
|
e13faebb | 2025-06-18 11:36:07 | xkbcli-interactive-wayland: Fix memory leak | |
|
69c3d257 | 2025-06-17 16:43:05 | keymap: Add parameter `latchOnPress` for LatchMods() Some keyboard layouts use `ISO_Level3_Latch` or `ISO_Level5_Latch` to define “built-in” dead keys: - they do not rely on the installation of custom Compose file; - they do not clash with other layouts. However, layout projects usually want the exact same behavior on all OS, but the XKB latch behavior (often misunderstood) also acts as a *set* modifier, which is not expected. The usual behavior of a dead key on Linux, macOS and Windows is: - latch on press; - deactivate as soon as another (non-modifier) key is pressed. Added the parameter `latchOnPress` to `LatchMods()` to enable the aforementioned behavior. As it is incompatible with X11, this feature is available only using the keymap text format v2. [XKB protocol key actions]: https://www.x.org/releases/current/doc/kbproto/xkbproto.html#Key_Actions | |
|
c58c7df1 | 2025-06-17 21:05:08 | Serialize multiple actions per level to VoidAction() in v1 format When using `XKB_KEYMAP_FORMAT_TEXT_V1`, multiple actions per level are now serialized using `VoidAction()`, in order to maintain compatibility with X11. | |
|
4f2fa718 | 2025-06-17 16:47:20 | dump: Fix typo Fixed copy-paste error. It worked for now, as both struct have the same first fields, but it is obviously semantically incorrect and not future-proof. | |
|
ee50e0c9 | 2025-06-12 20:14:50 | keymap: Add option `unlockOnPress` for LockMods() It enables e.g. to deactivate CapsLock on press rather than on release, as in other platforms such as Windows. The specification of `LockMods()` is changed to: - On key *press*: - If `unlockOnPress` is true and some of the target modifiers were *locked* before the key press, then unlock them if `noUnlock` false. - Otherwise: - add target modifiers to *depressed* modifiers; - if `noLock` is false, add target modifiers to the *locked* modifiers. - On key *release*: - If `unlockOnPress` is true and triggered unlocking on key press, do nothing. - Otherwise: - remove modifiers from the *depressed* modifiers, if no other key that affect the same modifiers is down; - if `noUnlock` is false and if any target modifiers was locked before the key press, *unlock* them. It fixes a [12-year old issue] inherited from the X11 ecosystem, by extending the [XKB protocol key actions]. As it is incompatible with X11, this feature is available only using the keymap text format v2. [12-year old issue]: https://gitlab.freedesktop.org/xorg/xserver/-/issues/312 [XKB protocol key actions]: https://www.x.org/releases/current/doc/kbproto/xkbproto.html#Key_Actions | |
|
d9d82355 | 2025-06-12 09:13:27 | keymap: Add option `lockOnRelease` for LockGroup() It enables to use e.g. the combination `Control + Shift` *alone* to switch layouts, while keeping the use of `Control + Shift + other key` (typically for keyboard shortcuts). The specification of `LockGroup()` is changed to: - On key *press*: - If `lockOnRelease` is set, then key press has no effect. - Otherwise: - if the `group` is absolute, key press sets the *locked* keyboard group to `group`; - otherwise, key press adds `group` to the *locked* keyboard group. In either case, the resulting *locked* and *effective* group is brought back into range depending on the value of the `GroupsWrap` control for the keyboard. - On key *release*: - If `lockOnRelease` is not set, then key release has no effect. - Otherwise, if any other key was *pressed* after the locking key, then key release has no effect. - Otherwise, it has the same effect than a key press *without* `lockOnRelease` set. This is really useful for people coming from other platforms, such as Windows. It fixes a [20-year old issue] inherited from the X11 ecosystem, by extending the [XKB protocol key actions]. As it is incompatible with X11, this feature is available only using the keymap text format v2. [20-year old issue]: https://gitlab.freedesktop.org/xorg/xserver/-/issues/258 [XKB protocol key actions]: https://www.x.org/releases/current/doc/kbproto/xkbproto.html#Key_Actions | |
|
c2896b32 | 2025-06-12 09:16:54 | messages: Add new error "incompatible-keymap-text-format" | |
|
da2af4d3 | 2025-06-17 12:08:59 | xkbcli-list: Added `layout-specific` field for options | |
|
0106b357 | 2025-06-17 12:06:32 | registry: Add rxkb_option_is_layout_specific() Enable to query if an option accepts layout index specifiers to restrict its application to the corresponding layouts. | |
|
c4c531da | 2025-06-17 11:43:50 | rules: Add layout-specific options for RMLVO builder Change the signature of `xkb_rmlvo_builder_append_layout()` to accept an array of options. Also add tests for layout-specific options. | |
|
fab9d25b | 2025-06-17 11:43:22 | rules: Add support for layout-specific options Enabled specifying a layout index for each option, so that it applies only if the layout matches. The layout index is specified by appending immediately after the option name the `!` specifier delimiter and then the layout index, in decimal form and 1-indexed. Note that `!` was chosen instead of the usual `:` specifier delimiter, because some options contains `:`, e.g. `grp:menu_toggle`. `!` *cannot* clash with component names, because `!` is a token in the rules files and thus cannot be used as in component names. It is also vaguely similar to `:`, compared to e.g. `@` or `#`. Example: given the following rules: ! layout[any] option = symbol * opt1 = +s1:%i l2 opt2 = +s2:%i it may result in the following configurations: | Layout | Option | Symbols | | -------- | -------- | ------------ | | `l1` | `opt1` | `+s1:1` | | `l2` | `opt1` | `+s1:1` | | `l1` | `opt2` | `` | | `l2` | `opt2` | `+s2:1` | | `l1,l2` | `opt1` | `+s1:1+s1:2` | | `l1,l2` | `opt1!1` | `+s1:1` | | `l1,l2` | `opt1!2` | `+s1:2` | | `l1,l2` | `opt2` | `+s2:2` | | `l1,l2` | `opt2!1` | `` | | `l1,l2` | `opt2!2` | `+s2:2` | | |
|
52a4d9b0 | 2025-06-17 11:03:12 | rules: Require layout or variant to enable %i expansion Before this commit, the following rule would always match: ! model = symbols * = s:%i and set symbols to `s:1`, but the `:%i` is aimed to be used only when the rules header specifies the layout or the variant. Let’s be strict and disallow matching this kind of buggy rule. Emit an error message so that we can detect it. | |
|
ef6a550f | 2025-06-16 15:48:25 | Add xkb_keymap_new_from_rmlvo() Use the new RMLVO builder API to compile keymaps. | |
|
da5caabb | 2025-06-16 15: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. | |
|
2906c7ec | 2025-06-14 13:19:41 | rules: Fix parsing group index There was a typo that made parsing hexadecimal instead of the expected decimal format. | |
|
62fe73cb | 2025-06-10 17:33:14 | parser: Raise the layout limit to 32 | |
|
f7a61da7 | 2025-06-10 17:33:24 | doc: Update new layout count ranges | |
|
ac9cd053 | 2025-06-11 19:00:47 | test: Check extended layout indexes | |
|
80b8d9d1 | 2025-06-10 17:34:15 | dump: Adapt groups count to keymap format | |
|
717ce258 | 2025-06-11 18:34:15 | test: Refactor rules-file and state Split into dedicated functions fo better readability. | |
|
2535a3f9 | 2025-06-11 15:55:25 | rules: Convert macros into enums & inline functions This provides semantics and better type-check. | |
|
7f39be25 | 2025-06-10 15:46:45 | test: Use explicit keymap output format for test_compile_output() | |
|
9f3078eb | 2025-06-10 15:46:31 | dump: Use explicit format | |
|
0f89ad97 | 2025-06-09 19:26:13 | dump: Always use numeric group indexes The upcoming raise of the maximum groups count will require to use numeric group indexes instead of the syntax `GroupN` if groups > 8. Let’s not bother with handling two cases (group count ≤ 8 or > 8) and always serialize group indexes as numeric values. | |
|
f3386743 | 2025-06-09 16:44:54 | test: Use explicit keymap format in test_compile_output() | |
|
2acf5eca | 2025-06-09 16:26:56 | test: Use explicit keymap format in test_compile_buffer() | |
|
6c5ea6fc | 2025-06-09 16:15:20 | test: Use explicit keymap format in test_compile_string() | |
|
79e95509 | 2025-06-09 11:07:36 | test: Use explicit keymap format in test_compile_rules() | |
|
6d67bce5 | 2025-06-08 10:01:02 | doc: Towards and exhaustive compatibility page We need to track the compatibility with X11 with as much details as possible: - Transparency; - Facilitate answering issues by just pointing to the relevant page item; - Efficient reference documentation for development. | |
|
27ba56ae | 2025-05-07 10:55:24 | doc: Add initial documention for XKB_KEYMAP_FORMAT_TEXT_V2 | |
|
44c8deb2 | 2025-05-07 10:20:25 | Introduce keymap format v2 and make it the default for parsing - Added `XKB_KEYMAP_FORMAT_TEXT_V2`. - Made `xkb_keymap_new_from_names()` use the new keymap format. - Made the tools default to the new keymap format for input. This is in preparation for changes in the parsing & state handling. For now it changes nothing. | |
|
82ea2915 | 2025-05-06 17:22:22 | tools: Add options to use explicit keymap format The default output keymap format is `XKB_KEYMAP_USE_ORIGINAL_FORMAT`. | |
|
62712cfe | 2025-05-06 17:42:54 | bench: Add options to use an explicit keymap format | |
|
08149dae | 2025-05-06 16:23:04 | Add internal API to query and parse supported keymap formats | |
|
58397e94 | 2025-05-06 18:05:30 | Deprecate xkb_keymap_new_from_names() - Deprecate `xkb_keymap_new_from_names()` in favor of `xkb_keymap_new_from_names2()` - Add new changelog fragment type `deprecated`. - Change documentation to use the new function. | |
|
1a10f858 | 2025-05-06 18:05:06 | Add xkb_keymap_new_from_names2 This is just `xkb_keymap_new_from_names()` with an explicit keymap format. | |
|
16c079d6 | 2025-06-06 20:27:45 | chore: Rename is_absolute to is_absolute_path | |
|
39b4b670 | 2025-06-06 18:40:29 | Support including keymap components using %-expansion and absolute path Enable to use the same `include` features than *rules* files in *keymap components*: - *`%`-expansion*: `%H` home directory, `%S` sytem root and `%E` extra. - absolute file paths. This is useful if one wants to overwrite the system file with a user config (i.e. same name, but in `~/.config/xkb`), but still include the system file: ``` // File: ~/.config/xkb/symbols/de xkb_symbols "basic" { include "%S/de(basic)" key <AB01> { [z, Z] }; key <AD06> { [y, Y] }; } ```` Without the commit, using a mere `include "de(basic)"` would result in an include loop. Refactored by using the same code for rules and keymap components. | |
 |
eb0a1457 | 2025-06-01 18:06:59 | build(deps): bump dawidd6/action-download-artifact from 9 to 10 Bumps [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact) from 9 to 10. - [Release notes](https://github.com/dawidd6/action-download-artifact/releases) - [Commits](https://github.com/dawidd6/action-download-artifact/compare/v9...v10) --- updated-dependencies: - dependency-name: dawidd6/action-download-artifact dependency-version: '10' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> | |
|
16ba1af0 | 2025-06-01 19:51:47 | ci: Fix xkeyboard-config install Since xkeyboard-config 2.45 uses a symlink for: /usr/share/pkgconfig/xkeyboard-config.pc /usr/share/X11/xkb but meson cannot overwrite < 2.45 which used a regular file and directory. Fixed by first removing the files. This is still a hack and we should use a proper package update. | |
 |
bffbef88 | 2025-05-21 23:57:11 | build: Require Bison ≥ 3.6 Older versions don’t support `%define parse.error detailed`. Fixes: a3f1a9d3ba ("xkbcomp/parser: enable Bison detailed syntax error") | |
|
7888474d | 2025-05-16 14:06:18 | Bump version to 1.10.0 | |
|
324984f1 | 2025-05-17 06:49:49 | xkbcomp: Fix log for unknown default field | |
|
4e1fd49a | 2025-05-17 07:53:10 | scripts: Enable generating new range message codes | |
|
c3744cd3 | 2025-05-16 14:10:37 | test: Fix Compose log | |
|
9b4fd82b | 2025-05-13 11:46:46 | test: Skip checked arithmetic if not available | |
|
e9394b9f | 2025-05-13 10:47:22 | utils: Use explicit cast to prevent warnings | |
|
fb9fec18 | 2025-05-10 10:18:38 | xkbcomp: Checked arithmetic Use a polyfill for C23 checked arithmetic. This is a bit paranoid, as we expect the user to use only 32 bit integers, so the signed 64 bit integer we use to store the result should be more than enough. Use jtckdint v1.0: - repository: https://github.com/jart/jtckdint - commit: 339450d13d8636f05dcb71ba36efddb226db481e - removed all C++-specific code | |
 |
7a2aa9c9 | 2024-12-20 22:53:11 | Always retain later Compose sequence in case of conflict This ensures that it is always possible to override previous definitions, for example when `include`ing the system Compose file. Signed-off-by: Jules Bertholet <julesbertholet@quoi.xyz> | |
|
3a8bb1a1 | 2025-05-16 13:13:55 | compose: Fix sequence not fully overriden Previously if a new sequence did not produce a keysym or a string, the corresponding property was not overriden, possibly leaking the previous entry. - Fixed by always writting all the properties. - Also try to reuse the previous string entry, if possible, so that we avoid allocating. | |
|
9da1a2eb | 2025-05-16 10:33:43 | doc: Add license in generated doc | |
|
d018638d | 2025-05-16 09:35:39 | doc: Improve CSS | |
|
61a1e646 | 2025-05-15 17:24:50 | doc: Reformat release notes and include them in the HTML doc | |
|
bd552642 | 2025-05-15 17:20:44 | doc: Use custom alias to fix HTML tags unsupported by Doxygen Previous solution with `sed` is both overkilled and unreliable. Prefer a hack using Doxygen’s buit-ins, although we are not sure these are much more stable… 😓 | |
|
b5f7c843 | 2025-05-14 21:34:23 | doc: Add script to fix HTML tags unsupported by Doxygen |