Dmitry Timoshkov dmitry at codeweavers.com
Fri May 21 11:07:40 CDT 2010

Scott Ritchie <scott at open-vote.org> wrote:

> current X implementations: XKB (European) and XIM (Asian) compete with
> eachother

That's not an issue, Windows has exactly the same problem just because
asian languages keyboard support is very complicated, and other languages
don't need that complexity (and huge slow down due to that).

>  - If you have a key on your keyboard to switch between US mode and
> "input mode" that can input other keys then we don't handle this well

Then don't map the layout switcher keys to character keys :-)

>  - A keyboard layout other than US English will leave you screwed if
> you're on an asian language

Not really, if your charset is UTF-8.


> Solution: rip out the mess in X, put everything in IBUS instead.
>  - User Session IBus daemon running, X talks to it
>  - xkeyboardconfig would need to be merged into IBUS
>  - X would be happy to remove keyboard stuff so they can focus on Video
> instead

Keyboard support can't be removed from X11 due to backwards compatibility and
remote display support.

All this doesn't list the real problem with X11 keyboard layouts support -
that a layout doesn't have a locale associated with it. So switching a keyboard
layout would also switch the input locale. Of course, UTF-8 locale has been
invented exactly to workaround that, so who cares... But if the input locale
really existed in X11, UTF-8 would not be really needed.

UTF-8 charset introduced a lot of problems (it is multibyte -> needs very
expensive handling/specially written applications which are multibyte aware,
handling of multibyte strings is a lot more slower that single byte ones).
RedHat bugzilla had a bug once UTF-8 has been introduced that grep worked
50 times slower in UTF-8 locale in comparison to simple en_US, but that bug
has been happily closed fairly quickly without a fix.


More information about the wine-devel mailing list