XKBCONFIG extension: RFP?

[Sergey Udaltsov]

Hi ppl

Recently, one more time, Alan Coopersmith and me were discussing
incorrect (by design) way of dealing  with XKB configuration used by
GNOME. So, after Keith's request on IRC, I am describing the features
I would need from some imaginary X extension which could make 'broken
hack' something coherent with the current X architecture.

First, I'll briefly describe the problem in terms of simple use case.
Desktop user wants to configure the keyboard (through GUI, of course)
with several important points in mind:
- to be able to enter international characters (from one or several languages)
- to use all the keys on his keyboard - even extended, multimedia ones.
- to be able to fallback to existing system configuration

So, XKB extension can be used to configure the keyboard.
Unfortunately, XKB API is somewhat weak in this aspect. It provides
access to low-level components (keycodes, geometry, symbols, types,
compat - KcGSTC) - but does not say how they can be combined in a
valid way - which is usually non-trivial task.
XFree and XOrg provide the configuration method based on keymaps - but
they are rigid, they cannot be combined with some reasonable semantic.
Also, there is rule-based high-level approach in terms of
'rules/model/layout(variant)/option' (RMLVO) - which gives maximum
flexibility (especially since XFree 4.3.0 with 'multiple layouts'
feature) - and semantically protects from dealing with low-level
configuration components (KcGSTC).
Unfortinately, RMLVO model is not standartized - neither libs/API it
is using to configure X server - nor approaches to get the directory
of available configuration elements.
So, today, in order to utilize this most flexible approach, two basic
methods are currently in use:
- using private library libxkbfile (used in GNOME 2.6 - 2.8)
- launching X server utilities setxkbmap/xkbcomp (used in GNOME since till 2.4)
- combination of them (GNOME 2.10)
The directory of configuration elements is either built-in (GNOME till
2.4) or taken, on a file level, from X server (GNOME since 2.6)
NONE of these methods is architecturally correct, especially in terms
of the network transparency of X Window (not to mention compatibility
with X servers shipping without libxkbfile).
(More discussion is available here:
http://bugzilla.gnome.org/show_bug.cgi?id=152105, especially see
comment #13 by Ivan Pascal - and, sure XKB and X.Org docs)

So, IMHO it is required to create some new extension delivering
necessary functionality:

1. Ability to set configuration in RMLVO terms.

2. Ability to get from the server information regarding current
configuration (in terms of RMLVO). Sure, if server is configured using
low-level options, it can be indicated by retval or something.
Currently, this isusually done by analyzing the root window property
XKB_RULES_NAMES (never standartized, part of the reference implementation).

3. Ability to list (ids, short and long descriptions):
 - rules. Within ruleset:
   - models
   - layouts
   - variants (per layout)
   - options groups
   - options (per group)
Currently it is done by reading xorg.xml. It would be correct to
provide descriptions depending on locale (from env or explicitly
specified)

4. Ability to say whether particular layout(variant) can be combined
with others (for server not supporting multiple layouts, this function
would return == false)

5. Probably (especially actual for "bad", non-combinable layouts) -
ability to list the groups within the layout.

The X11 extension with this functionality would allow to create
architecturally correct user applications configuring the keyboard in
RMLVO terms.

So, I would appreciate comments on this idea. Especially I'd be
grateful to get the critics from Alan.

Cheers,

Sergey