- 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>
This is a nice intro to the documentation, and also preferably gently
pushes users to the "proper way" of using the library, which can be
confusing.
See also: http://fooishbar.org/tell-me-about/xkbcommon-intro/
Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita
Wismill
Jouke Witteveen
Simon Zeni
Peter Hutterer
Ran Benita
Bryce Harrington
Daniel Stone