These were made const when the structs were exposed in the API. Now they
are private and we shouldn't mess around with the UNCONSTIFY business.
Signed-off-by: Ran Benita <ran234@gmail.com>
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>
Still keep things as 'ctx' internally so we don't have to worry about
typing it too often, but rename the user-visible API back as it was
kinda ugly.
This partially reverts e7bb1e5f.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
These are two aggregate file types which are not used anywhere. We
maintain useful-enough backward compatibility in the parser, by treating
them as xkb_keymap. The keymap type allows for all types of components,
so they will still compile fine if they ever come up.
Signed-off-by: Ran Benita <ran234@gmail.com>
(This breaks the API.)
"context" is really annoying to type all the time (and we're going to
type it a lot more :). "ctx" is clear, concise and common in many other
libraries. Use it!
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Fix for xkb -> keymap change.]
Each context gets its own table, i.e. interning a string in one context
does not affect any other context.
The existing xkb_atom_* functions are turned into wrappers around a new
standalone atom_table object.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated for xkb -> keymap.]
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>
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>
Ran Benita
Daniel Stone