Edit

kc3-lang/libxkbcommon/changes

Branch :

  • Show log

    Commit

  • Author : Peter Hutterer
    Date : 2024-02-14 09:47:15
    Hash : 7a7a3b38
    Message : 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.

  • README.md

  • Fragments for the changelog

    This directory contains fragments for the future NEWS file.

    Introduction

    We use towncrier to produce useful, summarized news files.

    There are 3 sections types:

    • API: changes/api
    • Tools: changes/tools
    • Build System: changes/build

    There are 4 news fragments types:

    • Breaking changes: .breaking
    • Deprecated: .deprecated
    • New: .feature
    • Fixes: .bugfix

    Adding a fragment

    Add a short description of the change in a file changes/SECTION/ID.FRAGMENT.md, where:

    • SECTION and FRAGMENT values are described in the previous section.
    • ID is the corresponding issue identifier on Github, if relevant. If there is no such issue, then ID should start with + and some identifier that make the file unique in the directory.

    Examples:

    • A bug fix for the issue #463 is an API change, so the corresponding file should be named changes/api/463.bugfix.md.
    • A new feature for tools like #448 corresponds to e.g. changes/tools/+add-verbose-opt.feature.md.

    Guidelines for the fragment files:

    • Use the Markdown markup.
    • Use past tense, e.g. “Fixed a segfault”.
    • Look at the previous releases NEWS file for further examples.

    Build the changelog

    Install towncrier from Pypi:

    python3 -m pip install towncrier

    Then build the changelog:

    # Only check the result. Useful after adding a new fragment.
towncrier build --draft --version 1.8.0
# Write the changelog & delete the news fragments
towncrier build --yes --version 1.8.0