What's wrong with xkbcomp?

[Peter Hutterer]

On Wed, Sep 24, 2008 at 02:42:29AM +0100, Simos Xenitellis wrote:
> The next step in replacing xkbcomp would be to list any of the
> structures we many want to eliminate or reduce some of the fields.
> 
> xkb_keymap
>     |____ xkb_keycodes
>     |____ xkb_types
>     |____ xkb_compatibility
>     |____ xkb_symbols
>     |____ xkb_geometry


There's two stages involved.
Step 1: is to go from the RMLVO in setxkbmap into a xkb_keymap. This includes
trawling through rules files, etc.
Step 2: is to parse the xkb_keymap into the server's internal format.

Optimisations include:
For Step 1: 
   - leave the xkb_keymap around instead of regenerating it.
   - connect RMLVO and Ktcsg so you can get the former from the latter. This
     way you can check if an xkb_keymap is correct for a given RMLVO.
For Step 2: 
   - don't go through the fork, let the server parse it.
   - xkb_geometry isn't used by the server until a client actually requests it
     (AFAIK). maybe parsing can be deferred?
   - the xkb_XXX could be split into several files, only requiring reparsing
     e.g. xkb_symbols if the symbols change.
 
Cheers,
  Peter