Since every user building the library, even from git, doesn't need these
files anymore, there's no need to check for them (this goes for makekeys
as well).
The only remaining user is the update-keysyms target, but whoever will
run it again (if ever) will probably know what he's doing (at least
enough to run git diff before git commit). And the defaults should be
fine too.
Signed-off-by: Ran Benita <ran234@gmail.com>
This avoids a couple of special cases in the code, and is more
consistent. Since anyone who includes xkbcommon.h also gets
xkbcommon-keysyms.h, and anyone who include xkbcommon-keysyms.h would
want NoSymbol anyway, there's no down side.
Signed-off-by: Ran Benita <ran234@gmail.com>
This code uses a table and code derived from
http://www.cl.cam.ac.uk/~mgk25/ucs/keysym2ucs.c
The added API calls are:
xkb_keysym_to_utf32
xkb_keysym_to_utf8
[daniels: Changed API to be more in line with keysym_get_name, added
test, changed formatting to 4-space.]
If we can merge cleanly (i.e. use the entirety of one entry rather than
having to go level by level), then just reuse the existing symbols array
and skip the entire merge process.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
bison/flex-generated objects, when being run in a VPATH build with
--disable-dependency-tracking (i.e. Gentoo), would fail to be created
because automake didn't bother creating the destination directories
before trying to create the objects.
Fix this by depending on the destination directory stamp, which
according to the automake mailing list, should hopefully remain fairly
stable.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Add a test/dump.data file which contains the result we're expecting from
xkb_map_get_as_string run on a particularly complex set of keymaps, and
assert that the string representations are the same. This means that
any updates to xkb_map_get_as_string will also need to update the test
data, but should also ensure that we don't have any more parser
regressions.
Compared with diff to the output of setxkbmap + xkbcomp for the same
keymap; seems completely solid.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
A symbols file may contain a global, non key specific setting for
the group out-of-range handling method (wrap, clamp, redirect). Only
that:
* Its parsed and kept in the SymbolsInfo, but is not otherwise used in
any way (it's the same in the real xkbcomp).
* It's not used in any of xkeyboard-config files.
* It's not mentioned in the xkb specs (only the per-key ones).
* It doesn't make much sense anyway.
So remove the struct field, and emit an "unsupported, ignored" warning.
We don't increment the error count because of it, just continue (the
radio group warning just below is changed to do the same - there's no
reason to possibly abort the entire thing for it).
Signed-off-by: Ran Benita <ran234@gmail.com>
Conflicts:
src/xkbcomp/symbols.c
Instead of using NoSymbol in the map, we use num_syms == 0 to signify
the non-presence of a symbol. So instead of adding NoSymbol mappings
to the list regardless, detect them and set num_syms == 0.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The failure mode here is a little irritating:
- server loads map with ISO_Lock action
- server dumps keymap to string, including:
interpret ISO_Lock+AnyOfOrAll(None) {
action= NoAction();
};
as we don't (yet) print ISO_Lock actions
- client parses keymap from string
- client dumps keymap to string, including:
interpret ISO_Lock+AnyOfOrAll(None) {
};
- this results in a syntax error
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Some actions could also take relative rather than absolute parameters,
so they really needed to be signed instead of explicitly unsigned.
Oops.
Fixes, e.g., action= MovePtr(x=-1,y=+1), which was reported as
(x=+65535,y=+1).
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Add a non-extensive test to check that some basic things (e.g. rule
matching, var substitution, indexes and groups) work as expected.
Signed-off-by: Ran Benita <ran234@gmail.com>
Currently, if you pass in an rmlvo with an empty string for layout or
variant, it would not match layout and variant rules even with
wildcards. But if the rules file had set an appropriate default, and someone
passes in the empty string, than he should get the default.
NULL in this case signifies not wanting to match against the layout or
variant at all, and so the rule should still fail to match NULLs.
Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita
Daniel Stone
Rob Bradford