How to further enhance XKB configuration
: Enhancing XKB Configuration
Previous: The Basics
Next: Defining New Layouts
3. Enhancing XKB Configuration
Most of xkb enhancements concerns a need to define new output symbols
for the some input key events. In other words, a need to define a new
symbol map (for a new language, standard or just to feel more comfortable
when typing text).
What do you need to do? Generally, you have to define following things:
- the map of symbols itself
- the rules to allow users to select the new mapping
- the description of the new layout
First of all, it is good to go through existing layouts and to examine
them if there is something you could easily adjust to fit your needs.
Even if there is nothing similar you may get some ideas about basic
concepts and used tricks.
3.1. Levels And Groups
Since XFree86 4.3.0 you can use multi-layout concept of xkb
configuration.
Though it is still in boundaries of xkb protocol and general ideas, the
keymap designer must obey new rules when creating new maps. In exchange
we get a more powerful and cleaner configuration system.
Remember that it is the application which must decide which symbol
matches which keycode according to effective modifier state. The X server
itself sends only an input event message to. Of course, usually
the general interpretation is processed by Xlib, Xaw, Motif, Qt, Gtk
and similar libraries. The X server only supplies its mapping table
(usually upon an application startup).
You can think of the X server's symbol table as of a irregular table where each
keycode has its row and where each combination of modifiers determines exactly
one column. The resulting cell then gives the proper symbolic value. Not all
keycodes need to bind different values for different combination of modifiers.
<ENTER> key, for instance, usually doesn't depend on any
modifiers so it its row has only one column defined.
Note that in XKB there is no prior assumption that certain modifiers are bound
to certain columns. By editing proper files (see
keytypes) this
mapping can be changed as well.
Unlike the original X protocol the XKB approach is far more
flexible. It is comfortable to add one additional XKB term - group. You can
think of a group as of a vector of columns per each keycode (naturally the
dimension of this vector may differ for different keycodes). What is it good
for? The group is not very useful unless you intend to use more than one
logically different set of symbols (like more than one alphabet) defined in a
single mapping table. But then, the group has a natural meaning - each symbol
set has its own group and changing it means selecting a different one.
XKB approach allows up to four different groups. The columns inside each group
are called (shift) levels. The X server knows the current group and reports it
together with modifier set and with a keycode in key events.
To sum it up:
- for each keycode XKB keyboard map contains up to four one-dimensional
tables - groups (logically different symbol sets)
- for each group of a keycode XKB keyboard map contains some columns
- shift levels (values reached by combinations of Shift, Ctrl, Alt, ...
modifiers)
- different keycodes can have different number of groups
- different groups of one keycode can have different number of shift levels
- the current group number is tracked by X server
It is clear that if you sanely define levels, groups and sanely bind
modifiers and associated actions you can have simultaneously loaded up to
four different symbol sets where each of them would reside in its own group.
The multi-layout concept provides a facility to manipulate xkb groups
and symbol definitions in a way that allows almost arbitrary composition of
predefined symbol tables. To keep it fully functional you have to:
- define all symbols only in the first group
- (re)define any modifiers with extra care to avoid strange (anisometric)
behaviour
How to further enhance XKB configuration
: Enhancing XKB Configuration
Previous: The Basics
Next: Defining New Layouts
|
