kc3-lang/libxkbcommon/doc/compatibility.md

• Show log

  Commit

• Hash : 66f71890
  Author :
  Date : 2025-03-31T08:01:29
  

  symbols: Enable writing keysyms list as UTF-8 strings
  
  Each Unicode code point of the string will be translated to their
  respective keysym, if possible. An empty string denotes `NoSymbol`.
  When such conversion is not possible, this will raise a syntax error.
  
  This introduces the following syntax:
  
  ```c
  // Empty string = `NoSymbol`
  key <1> {[""]}; // NoSymbol
  // Single code point = single keysym
  key <2> {["é"]}; // eacute
  // String = translate each code point to their respective keysym
  key <3> {["sßξك🎺"]}; // {s, ssharp, Greek_xi, Arabic_kaf, U1F3BA}
  // Mix string and keysyms
  key <4> {[{"ξ", Greek_kappa, "β"}]}; // { Greek_xi, Greek_kappa, Greek_beta}
  ```
  
  It can also be used wherever a keysym is required, e.g. in `interpret`
  and `modifier_map` statements. In these cases a single keysym is expected,
  so the string should contain *exactly one* Unicode code point.
  

Download

---

Source

• doc/compatibility.md

• # Compatibility {#xkbcommon-compatibility}
  
  @tableofcontents{html:2}
  
  ## XKB support {#xkb-v1-compatibility}
  
  Relative to the XKB 1.0 specification implemented in current X servers,
  xkbcommon has removed support for some parts of the specification which
  introduced unnecessary complications.  Many of these removals were in fact
  not implemented, or half-implemented at best, as well as being totally
  unused in the standard dataset.
  
  ### Notable removals
  
  - Keymap components are no longer mandatory, e.g. a keymap without a
    `xkb_types` section is legal.
  - geometry support @anchor geometry
    @anchor geometry-support
    + there were very few geometry definitions available, and while
      xkbcommon was responsible for parsing this insanely complex format,
      it never actually did anything with it
    + hopefully someone will develop a companion library which supports
      keyboard geometries in a more useful format
  - KcCGST (keycodes/compat/geometry/symbols/types) API
    @anchor KcCGST-support
    + use RMLVO instead; KcCGST is now an implementation detail
    + including pre-defined keymap files
  - XKM support
    + may come in an optional X11 support/compatibility library
  - around half of the interpret actions
    + pointer device, message and redirect actions in particular
  - non-virtual modifiers
    + core and virtual modifiers have been collapsed into the same
      namespace, with a 'significant' flag that largely parallels the
      core/virtual split
  - radio groups
    + completely unused in current keymaps, never fully implemented
  - overlays
    + almost completely unused in current keymaps
  - key behaviors
    + used to implement radio groups and overlays, and to deal with things
      like keys that physically lock; unused in current keymaps
  - indicator behaviours such as LED-controls-key
    + the only supported LED behaviour is key-controls-LED; again this
      was never really used in current keymaps
  - xkbcommon has stronger type checks, so floating-point numbers cannot
    be used where an integer is expected.
  - exponent syntax for floating-point numbers is not supported.
  - legacy merge mode `alternate` is not supported and is ignored.
  - support the merge mode *replace* in include statements via the
    prefix `^`, in addition to the standard *merge* `|` and *override*
    `+` modes.
  
  On the other hand, some features and extensions were added.
  
  ### Notable additions
  
  - 32-bit keycodes
  - extended number of modifiers (planned)
  - extended number of groups (planned)
  - multiple keysyms and actions per level
    + such levels are ignored by x11/xkbcomp.
  - key names (e.g. `<AE11>`) can be longer than 4 characters.
  - keysyms can be written as their corresponding string, e.g. `udiaeresis`
    can be written `"ü"`. A string with multiple Unicode code points denotes
    a list of the corresponding keysyms. An empty string denotes the keysym
    `NoSymbol`.
  
  ## Rules support {#rules-support}
  
  ### Additions
  
  - `! include` statement.
  - Support the merge mode *replace* via the prefix `^`, in addition to
    the standard *merge* `|` and *override* `+` modes.
  - Additional wild cards:
    - `<none>` matches *empty* value;
    - `<some>` matches *non-empty* value in *every* context.
    - `<any>` matches *optionally empty* value in *every* context, contrary to the
      legacy `*` wild card which does not match empty values for layout and
      variant;
  
  ## Compose support {#compose-support}
  
  Relative to the standard implementation in libX11 (described in the
  Compose(5) man-page), some features are not supported:
  
  - the (! MODIFIER) syntax
      + parsed correctly but ignored.
  - using modifier keysyms in Compose sequences
  - several interactions with Braille keysyms
  

Download