Currently the IDs are assigned from a static variable inside
CreateXKBFile. This can lead to some unpleasantness with threads, so
maintain the counter in the context instead.
Signed-off-by: Ran Benita <ran234@gmail.com>
We will need the context to remove some global state.
Also make the Parse* function just return bool while wer'e at it.
Signed-off-by: Ran Benita <ran234@gmail.com>
makekeys must be built with the build-native compiler, not with $(CC)
which is the cross-compiler. The only sane way to achieve this seems to
be to use a separate Makefile.am for it.
This patch fixes the problem apparently caused by:
commit b5efe41f19
Author: Ran Benita <ran234@gmail.com>
Date: Sat Mar 24 04:48:31 2012 +0200
Make build non-recursive
There is no such thing as makekeys_makekeys_CC in automake.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
We depend on parser.h which is generated by flex during the build, so
use an explicit $(top_builddir) rather than a relative path.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Change them to refer to the string representation of the keysym's name
as a name rather than a string, since we want to add API to get the
Unicode printable representation as well.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Two new calls allow users to test the exact modifier state, including
verifying that no other modifiers but the ones you wanted are down.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
xkbcommon-names.h right now just contains a set of hardcoded modifier
strings that are most commonly used for the usual modifiers. Provide
definitions of these so people don't have to worry about typoing a
string or mixing up Mod1 and Mod4.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Make the files in the src/* directory use their own header or a
consilidated private header. This makes the file dependencies clearer.
Also drop the pointless "xkb" file name prefix, add split a few
declarations to their own files (atom.h and text.h).
Signed-off-by: Ran Benita <ran234@gmail.com>
The include dependencies were quite convoluted, where you change the
order and get a ton of errors. Instead, change one file to act as the
internal interface for the xkbcomp files, and make every file use it.
Also drop the pointless "xkb" prefix to file names.
Signed-off-by: Ran Benita <ran234@gmail.com>
clang complains with the xorg-macros warning flags:
src/context.c:58:36: error: extension used [-Werror,-pedantic,-Wlanguage-extension-token]
typeof(new_paths));
This was not entirely correct, too. So bring back the casts to the
results of the allocation macros; might as well make them a bit more
type safe.
Signed-off-by: Ran Benita <ran234@gmail.com>
Fixes an 'unused' warning. There seems to be nothing wrong with these
sections though, all the tests pass.
Signed-off-by: Ran Benita <ran234@gmail.com>
This reverts commit d007cd0a1f.
This is in fact more restrictive, because it breaks the (common) case
where the strings are const themselved, e.g. "evdev", "us", etc. As is
you must either duplicate the strings or suppress the warnings.
If the user needs to retain the non-const strings, he should instead
just keep them in some other struct and use xkb_rules_names just as
a temporary parameter for xkb_map_new_from_names. Mildly annoying but
acceptable.
The two files do exactly the same sort of things, without any discernible
reason for splitting them.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated for xkb_desc -> xkb_keymap changes.]
'Cause defining your own True and False is so 1990's.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Fixed for xkb_desc -> xkb_keymap changes.]
Since the most common failure mode here is a failure to properly set the
XKB data path, dump the include path so people at least have a clue
where to look.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
POSIX specifies that these functions require <strings.h>, but we were
only including <string.h>. It did work, but still.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Rewrite all of the current tests in the following ways:
- Instead of the current mix of C and shell, just use single-process
pure C file per test. All of the .sh files are removed, but everything
that was tested is ported.
- Instead of handling the test logs ourselves, use Automake's
"parallel-test" mechanism. This will create a single log file for each
test with it's stdout+stderr, and a top level "test-suite.log" file
for all the failed tests.
- The "parallel-tests" directive also makes the test run in parallel,
so "make check" runs faster.
- Also use the "color-tests" directive to have the "make check" output
colorized. Who doesn't like to see PASS in green?
- All of the test data files are moved into the test/data subdirectory.
That way we can just put the directory in EXTRA_DIST and forget about
it.
- The test/Makefile.am file is consolidated into the main Makefile.am,
for a completely non-recursive build.
Right now the tests are completely independent and just use simple
assert()'s. More sophistication can be added as needed.
It should also be noted that it's still possible to use shell, python,
etc. if a test wants more flexibility than C can provide, just do as
before.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated for xkb_keymap changes.]
This is very useful because it avoids redundent pointers in structs
and/or parameter passing in the application.
Signed-off-by: Ran Benita <ran234@gmail.com>
The definitions in config.h should be available in all files an
implementation detail; it can be included through the build system
instead of having each file pull it every time.
This is especially helpful with AC_USE_SYSTEM_EXTENSIONS, as _GNU_SOURCE
and friends can have an effect by merely being defined, which can lead
to some confusion if its effective for only half the files.
And we don't really support a build _without_ config.h; so, one less
thing to worry about.
Signed-off-by: Ran Benita <ran234@gmail.com>
These are no longer needed for using the library, only building it. Most
users would still want xproto though, for the keysym definitions.
Signed-off-by: Ran Benita <ran234@gmail.com>
The kbproto header is already not needed here anymore.
Move the _X_EXPORT's to the corresponding function definitions, and use
straight extern "C" clauses instead of _XFUNCPROTOBEGIN/END.
It also makes more sense to have the EXPORT's in the source files, as it
provides some documentation to the reader, whereas in the header it's
obvious.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated for xkb_keymap changes.]
xkb_state_ref was missing.
Also modify the _ref functions to return the object instead of being
void. This is a useful idiom:
struct my_object my_object_new(struct xkb_state *state)
{
[...]
my_object->state = xkb_state_ref(state);
[...]
}
Essentially "taking" a reference, such that you don't forget to
increment it and it's one line less (see example in our own code).
A case could also be made for _unref to return the object or NULL, but
this is quite uncommon.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated for xkb_keymap changes.]
When merging group info from two KeyInfo's, the new size of the keysym
array was off. Fix it to match how it is used a few lines below.
There are also some peripheral fixes, and some comments (took me a
few minutes to get what's going on).
Signed-off-by: Ran Benita <ran234@gmail.com>
(They were not reported, see next commit).
The reset function declaration didn't match its name in the definition;
the _defaults variant matches better with the rest.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated to current master.]
Ran Benita
Pekka Paalanen
Daniel Stone
Alan Coopersmith