Yesterday I've committed last changes to the project before the pre-release freeze. The POT file is sent to the Translation Project. No more new models/layouts/variants/options, just bugfixes - till 29.09.

TWIMC

Please help reviewing the ISO codes, submit bugs either here or in fd.o bugzilla. Thanks, thanks, thanks.

I need to implement keyboard layouts for several african languages, some with complex tonal marks: acute, grave, grave with dot below, acute with dot below (these are the ones i know now, but there may be others). many of these characters do not have unicode code points of their own but they can be represented using combining diacritical marks: ie S with acute and dot below is S + U+0300 U+0323 - this is what i understand but i may be wrong so please correct me. 
My question is how do you implement such solution on linux? looking at the Compose file for en_US.utf8 it seems composing sequence characters can only be mapped to another unicode code point: eg. <Multi_Key> <U10001100> <U10001100> : "'' " U1101
How do you compose keys with multi_key or dead keys that emit more than one code point? 
Can this be implemented in the xkb keyboard layout/variant file? if so, how?

Thanks
Chris

These days a lot of people contribute new layouts/variants/models to xkeyboard-config. Usually it is done through the freedesktop.org's bugzilla. Quite often that contributed code requires manual "polishing" which would be unnecessary if authors would follow some simple rules. Till today, they really could not be blamed - because these rules existed only in my head. Now, these rules are published. So do not tell me you were not warned ;)

PS I still highly appreciate every contribution to the project. I just would like to make my life a bit easier. Thanks for understanding.

There is probably a bit too many libraries related to the keyboard - in X Window System in general, and GNOME in particular. In order to explain their not-too-complex relationships and their places in the whole puzzle, I am giving some short reference here.

libxkbfile

Language: C
Licence: X11
Bugzilla: Xorg

Strictly speaking, this library does not exist. Well, technically it does - but it was never meant to be public. Well, unfortunately it is de facto public now - for a long while. Why? Because there are several things in XKB which have never got proper network-transparent solution. In particular - dealing with keyboard configuration in terms of rules/models/layouts/variants/options (RMLVO). In the reference X Window System implementation, libxkbfile is handling RMLVO. It was originally designed as internal library linked to X server and several command line utilities like xkbcomp and setxkbmap. It was never network-transparent, it works with local keyboard configuration database files directly - which means it cannot properly support with remote X server (except for special environments using NFS etc).

This is one of many dark corners of X - the library which should not be used by anything but X implementation internally - but it is actually used quite often.

This library is installed as a part of standard Xorg or XFree86 installation.

Commercial implementations of X may be shipped without this library. Or have this library broken. Or have XKB implementation which does not use this library. All these scenarios create a lot of troubles for "bad" (from X Window architecture POV) applications using it. The authors of these applications usually realize this fact - but they have no choice (the only alternative for them is some kind of functional regression).
In the long run, the applications will use new version of XKB protocol which would provide network-transparent solution. But for the "old" servers, they'd have to link to libxkbfile for many years to come.

libxklavier

Language: C
Licence: LGPL
Bugzilla: none

This library was created in attempt to generalize (and make environment-independent) the code dealing with XKB, from the GNOME keyboard indicator applet. It contains a lot of utility code for accessing the keyboard configuration in terms of RMLVO, tracking the keyboard state etc. Its purpose is to provide a foundation for applications like keyboard layout indicators and monitors, keyboard configurators, layout-aware window managers etc.

Initially the library depended on X Window and libxml2 APIs only. Later (during the GNOME 2.15 release cycle), it was ported to gobject-based architecture.

Currently, it is used in production in GNOME only - but it is also used in ongoing KDE4 development (as optional dependency).

The library uses libxkbfile internally, it also accesses keyboard configuration registry file locally. This makes applications using it "bad citizens" in X Window world (there is standing bug report in GNOME bugzilla). Once new version of XKB is provided, the network transparency is going to be restored (for conformant X servers).

The compatibility with original X Window keyboard handling ("xmodmap") is maintained but with low priority.

libgnomekbd

Language: C
Licence: LGPL
Bugzilla: GNOME

The internal GNOME library emerged from two virtual modules in GNOME CVS: libgswitchit and libkbdraw. The merger was performed during 2.17 development cycle, the original modules were immediately declared deprecated. The library contains GNOME code related to the keyboard: keyboard indicator widget (including plugin management), keyboard drawing widget, saving/loading configuration to GConf etc.

There is an interesting discussion here:

Again, layouts, countries, languages - what would be the most usable representation for the user. Everyone is welcome with ideas and comments.

Hello! I heard it is possible to configure xkb to serve keyboard layout for each application, so for example i can type in russian in browser and keep typing in english in xterm without switching between locales each time i switch to another window.

XKB configs seems to be very flexible (and arcane, too, of course) system. I deduced from the different sources (such as this community, and Keith Packard's papers) that it's very possible to have this system redesigned and wonder, won't the resulting system will be less flexible than current (as GNOME folks do, removing features as "confusing").

If the question is too wide, I might narrow it: is there active effort in redesigning xkb, and if it is, is there way to suggest particular features which should be supported in the result: I have the xkb config written nearly from scratch (due to the fact I was unable to figure out how to compose and tweak existing layouts to make it work exactly as I wanted), and it will be very frustrating if I unable to tweak future configuration to resemble my current settings.