For error handling code, it's nice to be able to pass NULL to these
function without worrying about segfaults ensuing. free() sets the
precedent here.
Also document this fact.
Signed-off-by: Ran Benita <ran234@gmail.com>
These are 'special intrest' function, like the logging functions, so
it's nice to have them in their own logical group.
Signed-off-by: Ran Benita <ran234@gmail.com>
We add a return value to the xkb_state_update_key and
xkb_state_update_mask, which reports to the caller which of the state
components have changed as a result.
This restores the XKB functionality of the XkbStateNotify and
XkbIndicatorsStateNotify events. See:
http://www.x.org/releases/current/doc/kbproto/xkbproto.html#Events
It is quite useful in some situations. For example, it allows an
application to avoid doing some work if nothing of relevance in the
state has changed. Say, a keyboard layout applet. Also useful for
debugging.
The deltas themselves are not provided, because I can't see a use case.
If needed, it should be possible to add some API for that.
In xkbcommon, keymaps are immutable, so all of the other *Notify events
from XKB are irrelevant.
Signed-off-by: Ran Benita <ran234@gmail.com>
Note first:
This commits breaks the ABI somewhat. If an application is run against
this commit without recompiling against the updated header, these break:
- xkb_state_layout_*_is_active always retuns false.
- xkb_state_serialize_mods always returns 0.
So it might break layout switching in some applications. However,
xkbcommon-compat.h provides the necessary fixes, so recompiling should
work (though updating the application is even better).
Split the enum to its individual components, which enables us to refer
to them individually. We will use that later for reporting which
components of the state have changed after update.
Signed-off-by: Ran Benita <ran234@gmail.com>
This adds a flags argument to xkb_keysym_from_name() so we can perform a
case-insensitive search. This should really be supported as many keysyms
have really weird capitalization-rules.
However, as this may produce conflicts, users must be warned to only use
this for fallback paths or error-recovery. This is also the reason why the
internal XKB parsers still use the case-sensitive search.
This also adds some test-cases so the expected results are really
produced. The binary-size does _not_ change with this patch. However,
case-sensitive search may be slightly slower with this patch. But this is
barely measurable.
[ran: use bool instead of int for icase, add a recommendation to the
doc, and test a couple "thorny" cases.]
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Currently xkb_keymap_num_leds() returns a count of valid (settable)
leds. Because the indexes might be non-consecutive, and some leds
might not be settable, it is incorrect to use this function for
iterating over the leds in the keymap. But this is the main use case of
this function, so instead of the current behavior we adapt the function
to the use case by making it return the needed range of iteration.
The caller needs to handle invalid intermittent indexes, though.
Signed-off-by: Ran Benita <ran234@gmail.com>
This function really needs a format argument, for symmetry with the
keymap creation functions. If we add new formats, we will almost
certainly want to add support for serializing it into a string. It would
also allow to convert from one format to another, etc.
The in the common case, the user would just want to use the format she
used to create the keymap; for that we add a special
XKB_KEYMAP_USE_ORIGINAL_FORMAT value, which will do that (it is defined
to -1 outside of the enum because I have a feeling we might want to use
0 for something else). To support this we need to keep the format inside
the keymap. While we're at it we also initialize keymap flags properly.
This changes the API, but the old xkb_map_get_as_string name works as
expected so this is the best time to do this.
Signed-off-by: Ran Benita <ran234@gmail.com>
This is useful to see whether the function was successful and whether
truncation occurred.
It just changes void -> int so shouldn't break API or ABI.
Signed-off-by: Ran Benita <ran234@gmail.com>
To make it look better and a bit more structured and informative.
Not all of the functions are converted to doxygen format, so this is not
finished.
Signed-off-by: Ran Benita <ran234@gmail.com>
This is to follow the general scheme set by all of the other API
functions.
Since no one is using these functions yet, we don't (actually better
not) add the old names to xkbcommon-compat.h.
Signed-off-by: Ran Benita <ran234@gmail.com>
Rename the functions to get keysyms by key/layout/level to fit with the
recent public API renames, and expose them.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Move xkb_map_* functions to xkb_keymap_*, xkb_key_* functions under
either xkb_keymap or xkb_state, and rename groups to layout in all
user-visible API.
Backwards-compatible hooks are provided, such that old source will
build, but silently mangled to the new names, and old binaries will
also continue to work.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
- Add context.h and move context-related functions from xkb-priv.h to
it.
- Move xkb_context definition back to context.c.
- Add keysym.h and move keysym upper/lower/keypad from xkb-priv.h to it.
- Rename xkb-priv.h to map.h since it only contains keymap-related
definitions and declarations now.
- Remove unnecessary includes and some and some other small cleanups.
Signed-off-by: Ran Benita <ran234@gmail.com>
With Dan Nicholson's permission (via email), update his copyright and
license statements to the standard X.Org boilerplate MIT license, as
both myself and Ran have been using.
Clean up my copyright declarations (in some cases to correct ownership),
and add copyright/license statements from myself and/or Ran where
appropriate.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
As there is currently no stable release of xkbcommon, other projects might
want to include a copy of the keysyms so they can be used even though
libxkbcommon may not be available on the machine. However, if xkbcommon.h
is still included, conflicts will occur. Hence, to avoid nasty hacks,
simply include a header protection in xkbcommon upstream.
[daniels: Added protection to Makefile.am's update-keysyms, as well as
XKB_KEY_NoSymbol, and a comment noting that it shouldn't be
updated directly.]
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
In file included from external/collabora/libxkbcommon/src/xkb-priv.h:87,
from external/collabora/libxkbcommon/src/xkbcomp/xkbcomp.h:30,
from external/collabora/libxkbcommon/src/xkbcomp/xkbcomp-priv.h:30,
from external/collabora/libxkbcommon/src/xkbcomp/action.h:30,
from external/collabora/libxkbcommon/src/xkbcomp/action.c:27:
external/collabora/libxkbcommon/xkbcommon/xkbcommon.h:279: error: expected declaration specifiers or '...' before 'va_list'
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Now that we don't use syslog, "level" does sound more commonplace. We
should change it while there is still nobody using it.
Also leave some space between the integers of the xkb_log_level enum
values, if we ever need to shove more in between.
Signed-off-by: Ran Benita <ran234@gmail.com>
This function was always returning -1.
Adding a test, we see that test/state.c treat the is_active functions as
returning booleans, which would treat -1 as success, so we test for > 0
instead (most users would probably get this wrong as well...).
Also update the documentation for the are_active functions, and add a
ATTR_NULL_SENTINEL for gcc __attribute__((sentinel)).
Signed-off-by: Ran Benita <ran234@gmail.com>
A fairly simple helper which, given an xkb_mod_mask_t, removes all
modifiers which are consumed during processing of a particular key.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Currently the user has no way of knowing which of the active modifiers
have been used in the translation of a keycode to its keysyms. The use
case is described in the GTK docs: say there's a menu accelerator
activated by "<Alt>+". Some layouts have "+" shifted, and some have it
on the first level. So in keymaps where "+" is shifted, the Shift
modifier is consumed and must be ignored when the user is testing
for "<Alt>+". Otherwise, we may get "<Alt><Shift>+" and the accelerator
should not actually fire.
For this we also use the preserve[] information in the key types, which
can forces us to report modifiers as unconsumed even if they were used
in the translation. Until now we didn't do anything with this
information.
The API tries to match its surronding. It's not very efficient but this
can be fixed.
Signed-off-by: Ran Benita <ran234@gmail.com>
These were repeated 5 times.
Note that this changes the ABI slightly: XKB_MOD_NAME_CAPS is changed
from "Caps Lock" to "Lock", which is the ordinary legacy mod name for
it. Since its hidden behind a #define, it's best to stay compatible with
the old names (as I think was intended, given that "Mod1", etc. are the
same).
Signed-off-by: Ran Benita <ran234@gmail.com>
Add new public API to provide the library users with some options to
control and customize the logging output from the library. It is based
upon the skeleton from the libabc demo libray:
https://git.kernel.org/?p=linux/kernel/git/kay/libabc.git
which is public domain and works pretty well.
This requires passing in the context object in every logging call, and
thus the conversion is done file by file. We also remove the global
warningLevel variable in favor of a verbosity level in the context,
which can be set by the user and is silent by default.
One issue is the ACTION calls, which, while nice, do not play very well
with line- and priority-based logging, and would require some
line continuation handling or keeping state or some other compromise. So
instead remove these and just inline them with their respective
warning/error. So instead of:
ERROR("Memory allocation failed\n")
ACTION("Removing all files on hardisk\n")
its something like that:
log_err("Memory allocation failed; Removing all files on harddisk\n")
Signed-off-by: Ran Benita <ran234@gmail.com>
The include/ dir is somewhat redundant and makes it just a bit harder to
handle the -I directives from out side of automake; without it the
default $(top_buildir) just works.
Here's also some further justifications I found:
http://smcv.pseudorandom.co.uk/2008/09/pc-uninstalled/
Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita
David Herrmann
Daniel Stone
Pekka Paalanen