XKB extension: problems and issues

Sergey V. Udaltsov <svu@gnome.org>

Basic areas

Specification

Protocol

API

XFree implementation (based on standard implementation)

API

Most significant problems

(Specification, Protocol, API) Fixed maximal number of groups – 4. Not much people affected, but there are some rare complaints.

(Specification) The configuration methods/policy are not specified directly – so implementations can have very different environments

(Specification) No standard configuration repository structure

(Protocol, API) No way to find out programmatically about available configuration options. The solution with xfree86.xml is most flexible but not network transparent (client programs have no way to find about server configuration options).

(Specification, API) There is no easy way to manage the configuration repository. The files are implementation-specific. The implementation of editing tools for the current repository is highly problematic.

(XFree) Ambiguous configuration scheme: people can work with symbols, geometry, rules, types, models, layouts, options, keymaps.

(Protocol, API) No easy way to find out the current configuration names (e.g. layout names, model etc). The implementations use undocumented root window property (not specified in XKB specs – just introduced in the reference implementation!)

(XFree, API) There is no way to “remember” several configurations, no way to make backup of the current configuration (store configuration info into property other then default). The API is private, not public

(Specification, API) The “keyboard state per main window” behavior is not supported directly. While it is possible to implement it on top of existing API – it should be in the core functionality – along with relevant window properties etc.

(Specification, API) The “keyboard state per group of widgets” behavior is not supported. While it is possible to implement it on top of existing API – it should be in the core functionality. (This functionality can be tricky to specify/implement due to the multiplicity of the widget sets).

(XFree) No clean API defined for X server to load the configuration. Currently, the xkbcomp utility is launched on the server. It would make sense to have it either as internal API call on the server – or better – invoke xkbcomp (or make API call) on the client side (from Xlib) and load the keyboard by the wire (this would allow working with the client-side configuration repository using simple file access methods).

(XFree) Currently, XKB extension is compiled into the server (and enabled/disabled using special configuration directives). It would make sense to have it as a separate module – loadable when necessary.

Credits

Thanks to Ivan Pascal for discussions and reviews.

2004-02-26T14:38:17