Definite's Extractor

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

Tag Archives: keyboard layout

On IBus Xkb intergration (3)

Yesterday Caius Chance, Jens Petersen and me discussed my approach.
Petersen raised an interesting question:

What if a user want to learn, say Zhuyin input method, on a French AZERTY keyboard by seeing the software keyboard layout?

Mmm, I did not think of that, though Zhuyin can still work on AZERTY keyboard by changing the layout to us-QWERTY. Nevertheless, it is always nice to have visualized software keyboard.

This let me back to further consider Hutterer’s approach.

Number pad on telephone and computers are a good analog for westerners to understand why CJK input methods are in current shapes. Number pads on phones look like:

1       2(abc)  3(def)
4(ghi)  5(jkl)  5(mno)
7(pqrs) 8(tuv)  9(wxyz)
*       0       #

While number pad on computer keyboards look like:

7(home)  8(↑)    9(PgUp)
4(←)     5       6(→)
1(End)   2(↓)    3(PgDn)
0(Ins)           .(Del)    

If what you need is number, you only need to switch layout among phone, computer, or system default. However, you need hack (i.e. input methods) to input English on top of them.

There are at least following setting combination to type English on number pad:

  1. IM: T9, Layout: Phone
  2. IM: T9, Layout: Computer
  3. IM: T9, Layout: System default
  4. IM: MultiTap, Layout: Phone
  5. IM: MultiTap, Layout: Computer
  6. IM: MultiTap, Layout: System default

Where

  • Layout phone: 3(def) key is always on top right, regardless the mark on the number pad.
  • Layout computer: 3(def) key is always on bottom right, regardless the mark on the number pad.
  • Layout system default: Location of 3(def) key depends the mark on the number pad.

Peter Hutterer mentioned in the case of mobile phone, symbol ‘3’ is bind to top right key, while we still need to interpret what symbol ‘3’ really means (should it be ‘d’, ‘e’, ‘f’ or just ‘3’) in input method level.

Thus, the question can be reformed as:

Where should we interpret “d e f” to 3?

Currently, I think this can be done in “im-variant” level.
But in this way, software keyboard visualizer need to aware of this, then it is able to show the sensible key layout.

Usefullness of Keyboard layout in input method.

My previous post elaborates the difficulties and reasons why most of the input methods developers won’t adopt to the xkb key layout framework. To sum up, if your input method needs and relies on exactly one layout (usually en-QWERTY), you can safely hug that layout if ibus is capable of setting that layout for you. That’s why I keep nagging Hutterer about the set/get function of xkb.

However, Peter Hutterer opened my eyes and leaded me to a new aspect to review the input method implementation. Using key layout terminology, Chinese input methods can have up to 6 levels:

  1. Input symbol level: Word roots or Pinyin/Zhuyin symbols.
  2. Lower case full width alphanumber and punctuation marks .
  3. Upper case full width alphanumber and symbols.
  4. English lower case alphanumber. (if IM support temporary English mode)
  5. English upper case alphanumber. (if IM support temporary English mode)
  6. Special/User-defined symbols.

We might also have a quasi-level: Selection key level. Although “1234567890” are widely used to select candidates, some people, however, find “asdfghjkl;” more effective. Doesn’t that deserves a quasi-level? 😛

Althogh libchewing does implement Zhuyin layout conversion and support full width alphanumber input. Using key layout representation has it own benefits:

  • Better screen keyboard support.
  • Better setting ui: so users can bind their own level triggers to every level.

So, thank you, Peter Hutterer!

Keyboard Layout Taxonomy Proposal

Currently the keyboard layout is categorized by countries, which might not be suitable because it may bring following issues:

  1. Country flags (which may cause political problems)
  2. Not fair for the countries which are not in the list, e.g. Australia, New Zealand, Singapore, etc…
  3. Some layout is also available in certain countries but not recognized, e.g. Dvorak in China and India.
  4. Produce redundancy, like QWERTY in US, CN, IN are actually the same, but need to list 3 times.

Proposed Keyboard Layout Taxonomy

Use the keyboard layout itself as categories, such like:

  1. QWERTY– Default
    • ja_JP
    • ko_KR
    • de_CH
    • fr_CH
    • it_CH
    • en_UK
  2. DVORAK
    • @lefthand
    • @righthand
  3. QWERTZ
    • de_CH
      • @SunDeadKey
      • @NOSunDeadKey
      • @Mac
    • fr_CH
    • it_CH
  4. AZERTY
    • fr_FR
    • fr_BE

This taxonomy is more concise than countries-oriented. Users do not need to scroll the long countries list; and input method developers can easily have brief idea that what are they going to deal with.