|
275ffa66
|
2025-03-13T21:28:35
|
|
tools: Make --kccgst xkbcli-compile-keymap option public
The new public option `--kccgst` enables to display the result of RMLVO
resolution to KcCGST components.
This option has the same function than `setxkbmap -print`. This is particularly
useful for debugging issues with the rules.
Before this commit it was a private API. This commit enables us to remove
the *internal* version of `xkbcli-compile-keymap`.
|
|
|
5cfd36ab
|
2025-02-14T10:35:49
|
|
tools: Do not load names from the environment by default
Our tools are debugging tools and as such we need to have complete
control to be able to reproduce setups. This is not currently the case,
as we do not use `XKB_CONTEXT_NO_ENVIRONMENT_NAMES` by default nor can
we set it.
So it is very easy to forget about the various `XKB_DEFAULT_*`
environement variables for the default RMLVO values, then to get puzzled
by unexpected results.
Added to that, these environment variables do not work correctly in
`xkbcli-compile-xeymap`: calling the tool without RMLVO values will
use these variables only if the RMLVO values are set explicitly empty or
if the various *constants* `DEFAULT_XKB_*` are empty. This is unexpected,
as the environment variables should *always* be used unless:
- `XKB_CONTEXT_NO_ENVIRONMENT_NAMES` is used (not the case here);
- the variable is empty; in this case the constants `DEFAULT_XKB_*` are
used.
Fixed by the following *breaking change*: make the tools use
`XKB_CONTEXT_NO_ENVIRONMENT_NAMES` *by default*, unless the new
`--enable-environment-names` option is used.
We also make `rmlvo` incompatible with `--enable-environment-names` for
now in the public tool, as else it requires a private API.
|
|
|
bcb16d29
|
2025-01-28T13:19:06
|
|
tools: Miscellaneous enhancements
|
|
|
b168623c
|
2025-01-28T13:24:14
|
|
tools: Enable using keymap file as a positional argument
|
|
|
313001ce
|
2025-01-28T13:48:02
|
|
tools: Add --keymap alias and enable loading keymap files
Add `--keymap` as a more intuitive alias to `--from-xkb`; it also makes
it consistent with `interactive-evdev`. It optionally accepts a keymap
file path; if the argument is empty or `-` then the keymap is read from
`stdin`.
|
|
|
628242b2
|
2024-11-14T18:09:03
|
|
tools: Add --test to compile-{keymap,compose}
The new flag `--test` enables to only test if compilation succeeds,
without printing the corresponding keymap or Compose file.
This is useful for quick feedback and to speedup some tests suites, e.g.
for `xkeyboard-config`.
|
|
a4f62fcd
|
2024-06-04T07:03:10
|
|
doc (manuals): clean and expand apropos results
Previously on FreeBSD/mandoc (probably affecting others), everything
except xkbcli was being listed twice and wrapping on standard console
in apropos because mdoc(7) names should not have spaces or be different
than the title.
Further, xkb is already parsed in search results by being in the name,
so expand xkb to "X keyboard" so that they match for apropos keyboard.
We did this already in xkbutils, which matches setxkbmap.
These don't need to be quoted literals, and - doesn't need to be escaped,
but I left them because there may be environments which are not to spec,
but I'm happy to ammend this commit if that cleanup seems desirable.
Co-authored-by: Ran Benita <ran@unusedvar.com>
|
|
d5c6b581
|
2020-07-27T11:24:06
|
|
tools: convert man pages from man format to mdoc format
The mdoc is more semantic and consistent.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
f439ce18
|
2020-07-25T11:17:11
|
|
tools: some minor changes to xkbcli
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
ce5eb1ac
|
2020-07-24T13:31:03
|
|
tools: link the tools against libxkbcommon.so only
The tools previously linked against a static version (by simply recompiling
everythiong). This isn't necessary, we can link them against libxkbcommon.so.
Only exception: The xbkcli-compile-keymap tool needs a private API for the
--kccgst flag. Avoid this by disabling this flag in the installed tool and
building the same tool, statically linked but not-installed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
cd119a28
|
2020-07-23T09:37:15
|
|
Drop use of ronn, switch to raw roff instead
Drop the ronn source files, check in the generated files instead. This gets rid
of the ruby+gem+ronn toolchain requirement at the cost of having to edit raw man
pages.
ronn files are as-generated but with the preamble and generation date removed.
The latter isn't important enough to keep, it'll just go stale for manually
maintained files and it's not worth setting up a configure_file() just for that
date.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|