Definite's Extractor

My findings on Life, Linux, Open Source, and so on.

On ibus-xkb intergration (2)

Today I re-read Hutterer’s blog, I find out he also suggested that language toggle can be done by switching keyboard layout. Unfortunately, input methdos are far more complex than that because of following reasons:

Input methods that don’t really bind to a keyboard layout

Namely, pinyin/phonetic based input methods. Pinyin just combines English alphabets to Chinese characters, no matter on QWERTY, DVORAK, or COLEMAK. A dvorak user expects dvorak “pinyin-layout”. But what should be shown in language bar?

Indeed, Peng Huang can copy-paste en-QWERTY and en-DVORAK to make zh-QWERTY-pinyin and zh-DVORAK-pinyin, but COLEMAK, QWERTZ, AZERTY users won’t be supported until Huang explicitly copies those layouts. Doesn’t that make layout package bloated?

Input methods that share keyboard layout

Some input methods share keyboard layout. For example Cangjie 3, Cangjie 5, Quick 3, Quick 5 all use Cangjie layout. What input method should zh-Cangjie mapped to?

One key, multiple symbols

It’s not uncommon multiple symbols are mapped to one key.
If I take it correctly, the keyboard layout is essentially key position -> keysym.

But think about input metod and keyboard layout on a mobile phone keypad. What symbol should the top right key map to? Normally it should be 3.
But you still need an IM to interpret “33”, which might be either “de” with T9,
or “e” with “standard abc”.

Perhaps, that’s why MS Window use the term “keylayout/input method” for their input support. 🙂

Back to ibus-xkb intergration.
Here I don’t want to discuss the technically details but UI.

There would be a list of language – input method – keyboard layout (or xkb setting) combination. Like:

en,,,us,
en,,,us,dvorak,
en,,,us,dvorak-classic,
en,,,gb,
en,t9,,keypad,
en,morse-code,,straight-key,
jp,anthy,,us,
jp,anthy,,jp,
jp,anthy,,jp,kana
zh,pinyin,,*,
zh,cangjie3,,us,
zh,cangjie5,,us,
zh,chewing,,us,
zh,chewing,et,us,
zh,chewing,hsu,us,

1st field is language.
2nd is input method (can be null if don’t need it ).
3rd is input method variant, like the custom Zhuyin layout (can be null if don’t need it ).
4th is keyboard layout (in xkb sense). ‘*’ is for following the system default layout.
5th is variant (in xkb sense).

The benefit of choosing these combinations are

  • Can invoke input method support on-the-fly. Invoke the IM module if you need one, deactive or free the IM module if you don’t need it.
  • Compatiable to both IBus and xkb.
  • IBus know which layout is needed for the IM.
  • Also support keypad and morse code input. 🙂

Although I prefer to let IBus handles the language combination switching,
I would like to know the better approach.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: