This is the continuation from these posts: part 1, part 2, part 3
This is the part where it all comes together, with (BYO) fireworks and confetti, champagne and hoorays. Or rather, this is where I'll describe how to actually set everything up. It's a bit complicated because while libxkbcommon does the parsing legwork now, we haven't actually changed other APIs and the file formats which are still 1990s-style nerd cool and requires significant experience in CS [1] to understand what goes where.
The below relies on software using libxkbcommon and libxkbregistry. At the time of writing, libxkbcommon is used by all mainstream Wayland compositors but not by the X server. libxkbregistry is not yet used because I'm typing this before we had a release for it. But at least now I have a link to point people to.
libxkbcommon has a xkbcli-scaffold-new-layout tool that The xkblayout tool creates the template files as shown below. At the time of writing, this tool must be run from the git repo build directory, it is not installed.
I'll explain here how to add the us(banana) variant and the custom:foo option, and I will optimise for simplicity and brevity.
Directory structure
First, create the following directory layout:
$ tree $XDG_CONFIG_HOME/xkb /home/user/.config/xkb ├── compat ├── keycodes ├── rules │ ├── evdev │ └── evdev.xml ├── symbols │ ├── custom │ └── us └── typesIf $XDG_CONFIG_HOME is unset, fall back to $HOME/.config.
Rules files
Create the rules file and add an entry to map our custom:foo option to a section in the symbols/custom file.
$ cat $XDG_CONFIG_HOME/xkb/rules/evdev ! option = symbols custom:foo = +custom(foo) // Include the system 'evdev' file ! include %S/evdevNote that no entry is needed for the variant, that is handled by wildcards in the system rules file. If you only want a variant and no options, you technically don't need this rules file.
Second, create the xml file used by libxkbregistry to display your new entries in the configuration GUIs:
$ cat $XDG_CONFIG_HOME/xkb/rules/evdev.xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE xkbConfigRegistry SYSTEM "xkb.dtd"> <xkbConfigRegistry version="1.1"> <layoutList> <layout> <configItem> <name>us</name> </configItem> <variantList> <variant> <configItem> <name>banana</name> <shortDescription>banana</shortDescription> <description>US(Banana)</description> </configItem> </variant> </variantList> </layout> </layoutList> <optionList> <group allowMultipleSelection="true"> <configItem> <name>custom</name> <description>custom options</description> </configItem> <option> <configItem> <name>custom:foo</name> <description>This option does something great</description> </configItem> </option> </group> </optionList> </xkbConfigRegistry>Our variant needs to be added as a layoutList/layout/variantList/variant, the option to the optionList/group/option. libxkbregistry will combine this with the system-wide evdev.xml file in /usr/share/X11/xkb/rules/evdev.xml.
Overriding and adding symbols
Now to the actual mapping. Add a section to each of the symbols files that matches the variant or option name:
$ cat $XDG_CONFIG_HOME/xkb/symbols/us partial alphanumeric_keys modifier_keys xkb_symbols "banana" { name[Group1]= "Banana (us)"; include "us(basic)" key <CAPS> { [ Escape ] }; };with this, the us(banana) layout will be a US keyboard layout but with the CapsLock key mapped to Escape. What about our option? Mostly the same, let's map the tilde key to nothing:
$ cat $XDG_CONFIG_HOME/xkb/symbols/custom partial alphanumeric_keys modifier_keys xkb_symbols "foo" { key <TLDE> { [ VoidSymbol ] }; };A note here: NoSymbol means "don't overwrite it" whereas VoidSymbol is "map to nothing".
Notes
You may notice that the variant and option sections are almost identical. XKB doesn't care about variants vs options, it only cares about components to combine. So the sections do what we expect of them: variants include enough other components to make them a full keyboard layout, options merely define a few keys so they can be combined with layouts(variants). Due to how the lookups work, you could load the option template as layout custom(foo).
For the actual documentation of keyboard configuration, you'll need to google around, there are quite a few posts on how to map keys. All that has changed is where from and how things are loaded but not the actual data formats.
If you wanted to install this as system-wide custom rules, replace $XDG_CONFIG_HOME with /etc.
The above is a replacement for xmodmap. It does not require a script to be run manually to apply the config, the existing XKB integration will take care of it. It will work in Wayland (but as said above not in X, at least not for now).
A final word
Now, I fully agree that this is cumbersome, clunky and feels outdated. This is easy to fix, all that is needed is for someone to develop a better file format, make sure it's backwards compatible with the full spec of the XKB parser (the above is a fraction of what it can do), that you can generate the old files from the new format to reduce maintenance, and then maintain backwards compatibility with the current format for the next ten or so years. Should be a good Google Decade of Code beginner project.
[1] Cursing and Swearing
No comments:
Post a Comment
Comments are moderated thanks to spammers