xkbdesc "upgrade": RFC

Hi all

Some while ago, xlib module in fd.o cvs got submodule xkbdesc. The only
purpose of this submodule was to maintain the i18n work on xfree86.xml
file used in xfree86 (and now, in xorg server as well).

Now, with the spreading of gnome 2.6, I get more bug reports related to
the layouts in xfree86. I (and other people) cannot properly fix these
bugs in timely fashion - even if the fixes are introduced into xfree
cvs, they do not appear in xorg tree immediately (and vice versa). And,
since next xfree version is ... long way from today, users won't see
fixes for a rather long time.

What I am intending to do and what I'd like to discuss here (if anyone
is interested) is separating all xkb configuration data into a single,
noarch package, with its own autoconf script. This approach have several
advantages:

- more frequent releases, not tied to any code changes - just to
new/fixed data chunks.

- restructured layouts/variants tree. Current xfree xkb tree is rather
chaotic - some layouts (like phonetics ones) should be demoted to
variants. Creating separate package would allow to cut the gordian knot
of the compatibility and put some proper layouts tree structure in
place.

- Within a single package, it is be easier to sync the meta-data
(xfree86.xml) and actual data.

So, I am going (unless discussion shows me that my idea is nonsense) to
take existing xkb configuration data into xkbdesc module (all covered by
good old x11 licence) and start asking layout maintainers to put the
updated stuff into it. At least one of the major xfree layout
contributors - Ivan Pascal - agreed to help me with the process. I am
confident together with Ivan we'll be able to keep the xkbdesc module in
a sync with xfree cvs tree - and hopefully better.

The final goal is to provide distribution maintainers with the latest,
easy-to-package, most consistent X keyboard configuration which could be
used by any X server (including commercial ones).

At some point later, I am going to add xmodmap configuration data (from
the gnome keyboard applet, xmodmap version) - but there can be licensing
issues, so no promises.

There are some initial discussions about major architectural changes
related to the keyboard handling in X - but I think this project is
useful in any case - whether these changes will take place or noe. The
database of the keyboard configuration is a valuable data which should
not be lost in any course of events.

I am not sure this is the right maillist to discuss this, so I apologize
if I take wrong destination.

Cheers,

Sergey