xkeyboard-config and modular release

[Mike A. Harris]

Sergey Udaltsov wrote:
>>It's nice to have a clean tree, but more important to not break
>>existing configs, so if it's just consistency and cleanliness,
> 
> Not only this. In xorg 6.7, there is a mixture of layout supporting
> "multiple layout" and the ones which do not. That is why people get
> this nice GNOME "XKB error" dialog - for non-compatible layouts. And
> there is no way to fix it finally without breaking user's config files
> - for example, for Canadian users (Hungarian, Mongolian etc).

Indeed.  Red Hat bugzilla gets inundated with bug reports from
Canadian, Hungarian and other users, to which we refer upstream,
as there is no way to fix what is there currently without larger
changes you propose.

All other distributions seem to get inundated with these problems
as well.  Attempting to solve the problems by applying ugly
distribution specific hacks that wont and should not be included
upstream is not a solution, as it just breaks something for some
other user, creating an ongoing and never ending maintenance
nightmare.

This is a problem that needs to be solved directly in the upstream
project IMHO, and xkeyboard-config seems to be the right solution
to the problem to me.


> Inconsistency in existing tree is really outrageous - users ask when
> they should look for variants - and when they should look for
> standalone layouts (xorg has 4 'se' layouts, 3 'hu' etc - not
> variants, layouts!).

I think this is caused due to bit rot over the years, and lack of
documentation and overall sanity in the xkb files.  My observation
has been that random users want a particular keyboard layout,
explore X to find it doesn't exist, they copy an existing layout
and modify it to their liking, then they submit bug reports to
their distribution vendor or to XFree86 or X.Org to request their
new custom layout be included.  Generally, every request is
honoured and the number of xkb layouts blooms each release.

Nobody really took charge of the problem until Ivan and yourself
came along to fix the underlying problem and to provide a more
solid framework for future enhancement.  It's unfortunate that
your work hasn't been included in X.Org already, but I hope
to see it integrated into X11R7 at least.


> In xkeyboard config ALL layouts are compatible with "multiple layouts"
> feature (and they ALL are moved from the 'symbols/pc' subdirectory to
> the 'symbols' directory - because old layout are not going to be
> supported).

That will be an absolute godsend.  The number of bug reports
received about this problem is staggering.  What's worse is people
don't care what the problem is, they just want a solution and feel
it is rediculous that it isn't solved yet.

Since it *is* solved though, it is a shame to not have the solution
integrated into the tree so everyone benefits.  I hope that it does
get integrated now.


>>users just because we can, that's a serious mistake I'd like to
>>avoid.
> 
> Of course. Understanding this, we are trying to introduce the
> compatibity rules, just to keep the compatibility on 'XkbLayout' level
> (--enable-compat-rules). But for SOME people using 'XkbSymbols'
> compatibility would be broken anyway - just because of the removal of
> the old obsolete (unmaintained, incompatible!) code.

I think that a small amount of growing pain is well justified for
long term sanity of a better design/solution.

> BTW, talking about configuration files. We changed the rules file name
> to 'base' (from 'xorg' which was derived from 'xfree86'). But it
> should not be a problem if xkeyboard-config is built with
> --with-xkb-rules-symlink option - so here we are also trying to
> protect users.

That was only a problem due to broken applications out there assuming
that if you're using an X server, it is XFree86.  I was shocked
at how many things hard coded "xfree86".  The ugly workaround of
course was to add a symlink from xfree86 -> xorg xkb rules file,
however my personal opinion about that, was that if we did that,
NONE of the broken applications would EVER get fixed for real, because
that meant doing a bit more work and reading Xkb API documentation
and doing things the right way.

As such, in our OS releases at least, I explicitly deleted the
xfree86 -> xorg symlink to force application authors to fix their
broken apps and libraries to query the server for the name of the
xkb rules file.  In order to be fair, I wrote a very small test
application which opened a connection to the X server, queried for
the rules file name, printed it to stdout, and exited, so that
people who didn't have the time to figure out how to do it
themselves, could just cut and paste my code and massage it to
fit their app/library as seen fit.

All of the apps/libs in our OS which hard coded the xkb rules file
were patched over time by us to do things "the right way" by using
my example code, as I knew the rules filename may very well be
changing to "base" eventually, and did not want to relive the
hundreds of bug reports again.

We still receive occasional bug reports about this, but they're
much less infrequent, as it appears upstream projects have fixed
most of their broken code out there.

As such, changing the rules filename to "base" IMHO is not a
problem at all.  If this happens, I will do the same thing I did
the last time things were renamed, to shake out any other broken
applications that were never fixed properly, and I recommend
all other distros/vendors do the same thing, to encourage
expediant resolution to broken apps/libs.  Compat symlinks can
always be thrown in as an 11th hour compatibility measure after
a full development cycle has punished broken app authors to
fix their software.  My experience so far is that this "tough love"
approach has worked well.

"You'll hate me now, but you'll love me later." so to speak.


> In a word - we realize the importance of the compatibility. And we are
> trying to be as compatible as we can. But we realize we cannot be 100%
> compatible - and since we are not, we are using this 'moment of
> breakage' in order to clean up the tree and introduce some logic in
> the layouts.

I think you guys have done as good a job as can be done, and
compatibility seems to be fairly good IMHO.  Any temporary growing
pains are a coin in the ocean, and well worth it, in particular
at a major change from X11R6 to X11R7.  Now is the time for any
major changes to occur, including anything that might cause
temporary inconveniences for a small number of users.

Hopefully xkeyboard-config will be incorporated into Xorg CVS head
soon.  Alternatively, OS vendors can just disable the Xorg supplied
broken xkb stuff and replace it with xkeyboard-config separately.
If the latter happens though, and nobody ends up shipping the
broken stuff that is in the tree right now, it would beg the
question why the tree isn't updated to the stuff everyone actually
decides to ship.   A bit early to speculate that perhaps.

It sure would be nice to see this fixed for once and for all though,
so we don't need to see the same bug reports reported over and over
again.

TIA