On ibus-xkb intergration
Couples of days ago, Peng Huang (the IBus author), Peter Hutterer (an xkb guru) and me were talking about integrating xkb and IBus. Peter Hutterer suggested that each input method should registers its own input symbols (e.g. Cangjie / Wubi word roots or Zhuyin symbols) to as an xkb layout. However, Huang did not seem too keen on this.
I, on the other hand, was eager to adopt in this idea. In chewing, there are 8 Zhuyin layouts to be dealt with, even after ignoring the QWERTY and DVORAK influence, still has 6 layouts. By adopting Hutterer’s framework, I can concentrate on converting Zhuyin symbols to characters without worrying the current system layout.
However, as a Chinese IM developer, I kind of understand why Huang was not interested and the humps on the road.
- Easier input method development. IM can just concentrate on converting their own symbols.
- Neither keysyms of English nor keycodes are reliable. So are IMs on top of them.
Problems of why most IMs won’t adopt the proposed framework:
- Perceived awareness: Most of the IM developers only know one or two layouts, they don’t know why this is important.
- Cross platform: How about the systems that don’t support the proposed framework?
- Bureaucracy: Currently IMs only need to submit their works to IM framework; with the proposed framework, they also need to submit the corresponding symbols to xkb community, which are alien to them.
- Input symbols are meaningless: Unless there is a corresponding IM to process them. Some input symbols might not even be in Unicode, so why bothers registering them as xkb layout?
- Console mode: Even if IM developers were diligent enough to register in xkb, their works would not be appreciated in console mode. FYI, ibus-fbterm is usable now.
- Selection keys: In Zhuyin, for example, key ‘1’ may either means ‘ㄅ’ or “select the 1st candidate”. Proposed framework does not quite addressing this, because IM developers still need to interpret what does the key means.
- Assumption of en-QWERTY is always available: Even if keycodes do change, as long as en-QWERTY is available, just hook on en-QWERTY layout keysyms then you will be fine. This is probably the main reason. 😛
We cannot really do much about the perceived awareness, cross platform, meaningless input symbols issues. But, we can join force with console key layout developers/maintainers, so “define once, use everywhere” can be achieved.
The “Selection keys” issue, which I confirmed with Hutterer about, should be dealt within IBus or IM level.