kc3-lang/libxkbcommon

• Show log

  Commit

• Hash : ca033a29
  Author :
  Date : 2019-09-03T11:23:14
  

  rules: add include statements to rules files
  
  The majority use-case for extending XKB on a machine is to override one or a
  few keys with custom keycodes, not to define whole layouts.
  
  Previously, we relied on the rules file to be a single file, making it hard to
  extend. libxkbcommon parses $XDG_CONFIG_HOME/xkb/ but that only works as long
  as there is a rule that matches the user-specified RMLVO. This works for MLV
  but not for options which don't have a wildcard defined. Users have to copy
  the whole rules file and then work from there - not something easy to extend
  and maintain.
  
  This patch adds a new ! include directive to rules files that allows including
  another file. The file path must be without quotes and may not start with the
  literal "include". Two directives are supported, %H to $HOME and %S for the
  system-installed rules directory (usually /usr/share/X11/xkb/rules).
  
  A user would typically use a custom rules file like this:
  
  ! option                =       symbols
    custom:foo            =       +custom(foo)
    custom:bar            =       +custom(baz)
  
  ! include %S/evdev
  
  Where the above defines the two options and then includes the system-installed
  evdev rule. Since most current implementations default to loading the "evdev"
  ruleset, it's best to name this $XDG_CONFIG_HOME/xkb/rules/evdev, but any
  valid name is allowed.
  
  The include functionally replaces the line with the content of the included
  file which means the behavior of rules files is maintained. Specifically,
  custom options must be defined before including another file because the first
  match usually wins. In other words, the following ruleset will not assign
  my_model as one would expect:
  
  ! include %S/evdev
  
  ! model                 =  symbols
    my_model              =  +custom(foo)
  
  The default evdev ruleset has wildcards for model and those match before the
  my_model is hit.
  
  The actual resolved components need only be in one of the XKB lookup
  directories, e.g. for the example above:
  
  $ cat $XDG_CONFIG_HOME/xkb/symbols/custom
  partial alphanumeric_keys
  xkb_symbols "foo" {
      key <TLDE> {        [      VoidSymbol ]       };
  };
  
  partial alphanumeric_keys
  xkb_symbols "baz" {
      key <AB01> {        [      k, K ]       };
  };
  
  This can then be loaded with the XKB option "custom:foo,custom:bar".
  
  The use of "custom" is just as an example, there are no naming requirements
  beyond avoiding already-used ones. Also note the bar/baz above - the option
  names don't have to match the component names.
  
  Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
  

• Files

• .azure-pipelines/
• .gitignore
• .uncrustify.cfg
• LICENSE
• NEWS
• PACKAGING
• README.md
• azure-pipelines.yml
• bench/
• doc/
• fuzz/
• meson.build
• meson_options.txt
• scripts/
• src/
• test/
• xkbcommon-x11.map
• xkbcommon-x11.pc.in
• xkbcommon.map
• xkbcommon.pc.in
• xkbcommon/

• Properties

• Git HTTP	https://git.kmx.io/kc3-lang/libxkbcommon.git
  Git SSH	git@git.kmx.io:kc3-lang/libxkbcommon.git
  Public access ?	public
  Description	keymap handling library for toolkits and window systems Upstream Homepage Github Fork Github
  Users
  Tags