RFC: a new solution to Input Method + Keyboard Layout

This is not related to KDE itself, but I’d like to hear some opinion from keyboard layout users, especially from those who use more than one keyboard layout.

Right now I’m designing a new feature for fcitx (for people who doesn’t know it, it’s an input method framework under Linux), currently called “input method group”. The goal of this feature is to solve the conflict between keyboard layout and input method (mostly conceptually) . It can also solve some other problem, but the original goal is about keyboard layout.

Before I introduce the feature, I’d like to talk about the problem itself first.

People need to type their own language with their keyboard. For most latin character based languages, keyboard layout is a good solution to them, because the number of different characters in their language is small enough to be handled by the keyboard (26 * (1..2)). But in CJK world (Chinese, Japanese, Korean), number of characters are so large (especially for Chinese, number of characters in Chinese is over thousand) that each character can’t be simply mapped to a key on the keyboard. So people invent input method, which basically maps a sequence of key to a limited number of characters and people can select from it.

But if we re-think about the keyboard layout itself, it can actually be considered as a very simple kind of input methods. The only difference is that the mappings from “keys” to “characters” in keyboard layout is much simpler than those in CJK input method. And that’s why keyboard layouts are handled as input method in modern OS, like windows and mac OSX, and ibus/fcitx nowadays.

It looks so far so good, until you remember that keyboard are not only used to type text. Suppose you want to type French and German, and you add them as your input methods. But hey, French layout is azerty and German is qwertz. Your favorite “Ctrl+Z” for undo is at the different position on the keyboard! If you add Chinese pinyin into consideration, it will be even more messed up. Not to mention if you want to use Dovrak layout with Pinyin and but pinyin is forced you to US layout on Windows.

Though keyboard layout can be considered as an input method, it’s actually a mapping from physical keys to virtual keys (and to characters). And regular CJK input method is a mapping from virtual keys to characters. So they should be able to composed arbitrary to serve user’s own need (e.g. Pinyin + Dovrak).

And we previously had a user provided one of his scenerio:

* Kain(fake name, you know) has two keyboards. One is laptop built-in with US layout, which he will use at  home. Another is a usb keyboard, but it’s in fr layout (key printing).
* He usually use Pinyin and Mozc to type Chinese and Japanese.

He want to automatically switch layout when he’s using different keyboard. While X/wayland doesn’t provide “per physical keyboard” layout (I don’t think “real” per physical keyboard layout is useful though, since you’ll still only use one physical keyboard at a time.), I’d like to support such use case and that’s why I invent the concept of “input method group”.

Basically a input method group contains a list of input methods, and has a layout. This layout will be the actual “system” layout. It affects all the hotkey bindings for your desktop. And for Kain’s use case

His configuration will look like this:
* Default group (us layout):
* Keyboard (default), Pinyin, Mozc
*
* Alternative group (fr layout):
* Input methods are the same as default.

And we can listen to udev event, once the keyboard is plugged in, automatically switch to group fr and he can happily type with fr layout.

For regular CJK user, they can stick to one group. For regular keyboard layout users who want old fashion keyboard layout like setup, they can use different groups with single “keyboard” input method.

And I’d also like to support multiple layout based input method in same group. With help with xkbcommon, this can be actually done. So you can have “Keyboard (US English)” and “Keyboard (Arabic)” in same group, but your system layout will always be US layout even you’re using “Keyboard (Arabic)” to type.

And I think it can also help users who only use some specific language at work and another language at home. And I think is fit quite well with KDE’s activities, e.g. bind different activities with specific input method group. After all, if you want 3 different input methods, but only two of them at a time, it would be easier to switch input method between 2 instead of 3.

What do you think of it? I’d like to make this feature supports the needs of both keyboard layout users and input method users. Do you have any other use case related that you want to share?

This entry was posted in KDE, Linux and tagged . Bookmark the permalink.

11 Responses to RFC: a new solution to Input Method + Keyboard Layout

  1. Pingback: Links 19/6/2016: Randa Over, Fedora 24 Release Soon | Techrights

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.