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>
It gives:
Warning: Tag `SYMBOL_CACHE_SIZE' at line 346 of file doc/Doxyfile has become obsolete.
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"
So run 'doxygen -u' as suggested.
Signed-off-by: Ran Benita <ran234@gmail.com>
The doxygen page looked a bit dead, the README fills it nicely, and is
already written in the markdown format which doxygen uses (I think?).
Unfortunately the USE_MDFILE_AS_MAINPAGE doxygen config doesn't seem to
do anything.. So we just add a {#mainpage} tag at the top of the README
which isn't so bad. BUT we still need some config option (the
no_extension=md part) so that doxygen will accept README instead of
README.md or somesuch. And that requires an even newer release, 1.8.3.1,
released 2013-01. But if an older version is used, it doesn't spew out
warnings but just skips the README, which is fine.
Signed-off-by: Ran Benita <ran234@gmail.com>
We want to use the USE_MDFILE_AS_MAINPAGE option which was introduced in
doxygen 1.8.3 (released 2012-12).
Right now the new options are commented, otherwise older doxygen spews
these these warnings, which can be ignored:
warning: ignoring unsupported tag `USE_MDFILE_AS_MAINPAGE =' at line 794, file doc/Doxyfile
warning: ignoring unsupported tag `MATHJAX_FORMAT =' at line 1210, file doc/Doxyfile
warning: ignoring unsupported tag `EXTERNAL_SEARCH =' at line 1257, file doc/Doxyfile
warning: ignoring unsupported tag `SEARCHENGINE_URL =' at line 1265, file doc/Doxyfile
warning: ignoring unsupported tag `SEARCHDATA_FILE =' at line 1271, file doc/Doxyfile
warning: ignoring unsupported tag `EXTERNAL_SEARCH_ID =' at line 1278, file doc/Doxyfile
warning: ignoring unsupported tag `EXTRA_SEARCH_MAPPINGS =' at line 1287, file doc/Doxyfile
Signed-off-by: Ran Benita <ran234@gmail.com>
Jouke Witteveen
Ran Benita
Simon Zeni
Peter Hutterer
Ran Benita
Bryce Harrington
Daniel Stone