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)
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:
- IM: T9, Layout: Phone
- IM: T9, Layout: Computer
- IM: T9, Layout: System default
- IM: MultiTap, Layout: Phone
- IM: MultiTap, Layout: Computer
- IM: MultiTap, Layout: System default
- 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.