Scott Ritchie scott@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.
[skipped]
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.