Usually it is better to use the corresponding human-friendly keysym
names. If there is none, then the keysym is most probably not
supported in the ecosystem. The only use case I see is similar to the
PUA in Unicode (see: https://en.wikipedia.org/wiki/Private_Use_Areas).
I am not aware of examples of this kind of use.
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
```
libxkbcommon/doc/introduction-to-xkb.md:67: warning: unable to resolve reference to 'rule-file-format' for \ref command
libxkbcommon/doc/introduction-to-xkb.md:181: warning: unable to resolve reference to 'keymap-text-format-v1' for \ref command
libxkbcommon/doc/rules-format.md:10: warning: unable to resolve reference to 'xkb-intro' for \ref command
```
Signed-off-by: Ran Benita <ran@unusedvar.com>
Doc URLs may change with time because they depend on Doxygen machinery.
This is unfortunate because it is good practice to keep valid URLs
(see: https://www.w3.org/Provider/Style/URI.html).
I could not find a built-in solution in Doxygen, so the solution proposed
here is to maintain a registry of all URLs and manage legacy URLs as
redirections to their canonical page.
This commit adds a registry of URLs that has three functions:
- Check no previous URL is now invalid.
- Add aliases for moved pages.
- Generate redirection pages for aliases. The redirection works with
a simple <meta http-equiv="refresh"> HTML tag. See:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta#http-equiv
This commit also initialize the URLs registry with current pages and some
redirections needed after recent documentation refactoring.
Finally, the CI is updated to catch any change that invalidate previous
URLs.
- Add table of contents
- Add terminology section
- (WIP) Add Introduction to the format
- Improve the keycode section
- Improve the interpret section
- Add guide to create and use modifiers
- (WIP) Add actions documentation
- Add cross-references
- Add keysyms header to documentation
It's a niche use-case but basically the same as adding symbols, so let's go with
a general handwavy explanation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This completes the usual triplet of configuration locations available for most
processes:
- vendor-provided data files in /usr/share/X11/xkb
- system-specific data files in /etc/xkb
- user-specific data files in $XDG_CONFIG_HOME/xkb
The default lookup order user, system, vendor, just like everything else that
uses these conventions.
For include directives in rules files, the '%E' resolves to that path.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This library is the replacement for clients parsing evdev.xml directly.
Instead, they should use the API here so that in the future we may even
be able to swap evdev.xml for a more suitable data format.
The library parses through evdev.xml (using libxml2) and - if requested -
through evdev.extras.xml as well. The merge approach is optimised for
the default case where we have a system-installed rules XML and another file in
$XDG_CONFIG_DIR that adds a few entries. We load the system file first, then
append any custom ones to that. It's not possible to overwrite the MLVO list
provided by the system files - if you want to do that, get the change upstream.
XML validation is handled through the DTD itself which means we only need to
check for a nonempty name, everything else the DTD validation should complain
about.
The logging system is effectively identical to xkbcommon.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Most of this is currently hidden in the commit message for ca033a29d2, let's
make it a bit more public so we have a link to point users to.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Useful to have this as part of the documentation. The rendering isn't great but
at least not any worse than pure text. Markdown escapes % so explaining our use
of %S and %H would require a double % - not idea. Let's just wrap it as a code
block and done.
Includes two typo fixes too, yay.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
keymap was defined in the X11 example, but also define it in the wayland
example just to make it a bit more standalone
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
xkb_context_new() returns a xkb_context pointer, so change the variable
definition to be consistent.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Instead of giving Doxygen a series of absolute paths to the source
files and a relative path to the output directory, run it from the
source directory with purely relative paths to the source files, and
give it an absolute path to the build directory.
This fixes the parsing of README.md with a separate build directory,
since the relative includes for doc/quick-guide.md and doc/compat.md
don't resolve otherwise. Doxygen's INCLUDE_PATH turns out not to fix
this either, since that's just a set of paths to open and parse, rather
than an analogue to cpp's -I.
Signed-off-by: Daniel Stone <daniels@collabora.com>
xkbcommon-compose is a Compose implementation for xkbcommon. It mostly
behaves like libX11's Compose, but the support is somewhat low-level and
is not transparent like in libX11. The user must add some supporting code
in order to utilize it.
The intended audience are users who use xkbcommon but not a full-blown
input method. With this they can add Compose support in a straightforward
manner, so they have a fairly complete keyboard input for Latin-like
languages at least.
See the header documentation for details.
Signed-off-by: Ran Benita <ran234@gmail.com>
It's easier to quickly go through the functions in a module this way.
The names provide enough "brief description" to get someone to click for
the full description.
Signed-off-by: Ran Benita <ran234@gmail.com>
Pierre Le Marre
Ran Benita
Jouke Witteveen
Simon Zeni
Peter Hutterer
Ran Benita
Bryce Harrington
Daniel Stone