Allow for merged KcCGST files and a system path #162

whot · 2020-07-10T05:54:46Z

Three additions in this branch, it sits on top of #160 otherwise, starting at commit
"Add asprintf_safe helper function"

`/etc/xkb` as lookup path

This adds /etc/xkb as a lookup path for system-wide keyboard configurations. Fixes #40, see my long comment on why just a single path and not a conf.d style directory.

So our lookup path sequence becomes - in that order:

XDG_CONFIG_HOME/xkb
$HOME/.xkb
/etc/xkb
/usr/share/X11/xkb

Which gives us roughly the same behaviour as most other tools that have config files.

`xkbcli scaffold` tool

All directories still need to adhere to the same folder structure since the folder names and file names are part of the API. To make it simpler to get started with a custom XKB layout, there's a new tool called xkbcli scaffold. So a user would run, e.g.

$ xkbcli scaffold --user --layout "us(myvariant)" --option "custom:foo"

And that would create the required bits in $XDG_CONFIG_HOME/xkb. All they need now is learn how XKB files work and fill them in :) Passing --system does the same in the new /etc/xkb folder. Otherwise it's a fairly simple tool and it only writes to files that don't yet exist so it's safe to call twice (though ineffective).

Merge-include behaviour for KcCGST files

And since it's currently not possible to have us(myvariant) (see the same comment), change the KcCGST include behavior to run through all include paths.
So an include statement like include "us(basic)" will be attempted in in all symbols/us files in the include paths until the first one that works is found. It's thus possible to have a custom variant extending a system layout like this:

$ cat $XDG_CONFIG_HOME/xkb/symbols/us
partial alphanumeric_keys modifier_keys
xkb_symbols "myvariant" {
    name[Group1]= "myvariant (us)";
    include "us(basic)"
    key <CAPS> { [ Escape ] };
};

And this does the right thing.

cc @fooishbar and @svu because while I think this is save to do, I'm not sure if there are hidden side effects I haven't though of.

bluetech · 2020-07-26T12:00:17Z

I'll review this when I get the next chance. In the mean time a rebase would be good.

Is this something you think 0.11.0 should include, or is it fine to release without?

whot · 2020-07-27T02:12:55Z

Rebased on top of #173 now.

I renamed the tool to xkbcli-scaffold-new-layout but marked it install: false until we know it's useful. Rest is the same but has seen a few improvements in the code handling. Marking it as ready

Is this something you think 0.11.0 should include, or is it fine to release without?

I think we should include it. 0.10.0 added the user-specific files but they were only usable in a narrow context. With libxkbregistry and this the handling of custom files is complete (I think) and we have a good replacement for xmodmap (and of course custom/experimental keyboard layouts). If we get that in 0.11 in one go, life is a bit easier for everyone including writing documentation.

At least on my TODO list the only thing left now is to fix the xkeyboard-config format to be less awkward, but that's not going to happen anytime soon...

bluetech

Hi @whot, I looked at the changes and they mostly look good to me. Sorry for the delay.

Note that it needs a rebase.

One high level comment regarding the KcCGST merging behavior:

The strategy you've used for this is to reduce the granularity from the file level to the map level. This is good. The first file which has a matching map is used. Another alternative is to merge the maps of all files together. XKB has a bunch of merging machinery for this, with 3 different merge keywords augment, override, replace. Have you considered using that somehow instead of first-wins? I haven't considered it deeply myself, but wanted to mention it.

bluetech · 2020-08-08T19:28:30Z

doc/user-configuration.md

@@ -11,6 +11,8 @@ libxkbcommon searches the following paths for XKB configuration files:
 - `$XDG_CONFIG_HOME/xkb/`, or `$HOME/.config/xkb/` if the `$XDG_CONFIG_HOME`
  environment variable is not defined
 - `$HOME/.xkb/`
+- `$XKB_CONFIG_EXTRA_PATH` if set, otherswise `<sysconfdir>/xkb` (on most


Perhaps we can skip this envvar, unless it's really needed?

But if we keep it, xkbcommon.h has a doc section that needs to mention it (search for envvars).

There's also a include-path section there that needs to be updated for /etc/xkb in general.

we sort-of need it for the tests. By overriding that variable we can test default include path handling without having to actually rely on correct configuration in /etc/

test/tool-option-parsing.py