This reverts commit c4c9e36fbf. It turns
out that the listing code is used to support the X_kbListComponents
request (via XkbListComponents).
This will have to be refactored into some reasonable interface instead
of the current usage where the server reads xkbcomp stdout. Gross.
Instead of hardcoding the XKB base directory when searching for rules in
the xkbcomp code, we can extend the xkbpath API to cover rules and reuse
it. That will make it more convenient if it's ever exposed so people can
set their XKB search paths in a reasonable way.
We need to support generating a keyboard description from a keymap file
because there are just some cases where RMLVO or ktcsg is not enough.
The map choosing logic has been refactored into its own function and now
supports choosing a named or default keymap.
The noble intention was to expose all the new API and new generic types
in the split out kbproto headers through XKBcommon.h. It turns out that
would be a massive amount of work in the server. Someday, but first just
wedging in XkbCompileKeymap* would be good.
Most of the API is in new internal xkb*.h headers. In order to allow the
XKBcommon.h header to be used from the server, we can't pull in other
headers from kbproto since the server has its own copies. However, types
that are different (XkbDescRec, XkbAction) still have Xkbc equivalents
here, and I think they should be used in the server.
Some of the XkbAction types are defined differently in the server, so we
add those to XKBcommon.h and use them here like XkbcDescPtr. We'll have
to deal with the impedance mismatch on the client side later.
XkbcRF_GetComponents was returning an error but leaving the generated
components alone. This ensures that the broken XkbComponentNamesPtr is
freed and the error is passed up to the caller.
Instead of requiring the user to call XkbInitIncludePath() and
XkbAddDefaultDirectoriesToPath(), all the path entry points now implicitly
initialize the path. When initializing, the default directories are added
so it's useful.
This provides normal operation without exposing the xkbpath API. That
might happen later to allow apps to edit the XKB search path.
XkbcCompileKeymapFromRules can be used to generate a XkbDescPtr from XKB
rules instead of using components. The previous XkbcCompileKeymap has
been renamed to XkbcCompileKeymapFromComponents.
Finally, we can generate a XkbcDescPtr from a XkbComponentNamesPtr. This
involves turning the components into a parsed XKB file and then passing
it into the compiler. This first conversion needs more error handling.
xkbcomp was using Xlib's XConvertCase to check upper/lowercase. That's a
lot of code, so hopefully the xkbfile macros using _XkbKSCheckCase are
good enough. This also required that <X11/keysym.h> is included to get
all the XK_* definitions.
Added common variants of XkbComputeEffectiveMap, XkbInitCanonicalKeyTypes
and all their needed functions. A couple functions that were in alloc.c
moved to malloc.c to mirror the libX11 sources better.
Original code in
libX11/src/xkb/XKBMalloc.c
libX11/src/xkb/XKBMisc.c
libX11/src/xkb/XKB.c
This should cover all the usage in xkbcomp. The format arguments were
dropped except for the special case of XkbModMaskText, which needs to
write in XkbCFile format in HandleVModDef. This was just changed to a
Bool to avoid the need for the macros in XKBfile.h.
The function prefixes have been renamed to be unique from xkbfile.
The only real usage was in the frontend to generate a .xkm file. The
rest of the code just operated on the attached XkbDescPtr. Note that
here we've replaced the usage of the defined field in CompileKeymap with
the equivalent field in a XkbcDescPtr.
A copy of the xkbcomp sources (except the frontend) have been copied in
to provide a means to compile a XkbDescPtr. This definitely doesn't
build or do the right thing yet.
Dan Nicholson