I wrote some post about “Why Fcitx” before, while I was little bit worried about fcitx’s future. But for now, I already have some idea for this question.

There is already several input method framework on Linux world, why Fcitx is needed? First let’s review the history of Fcitx. Fcitx was born in 2002, which by that time was named “gWubi”. It got renamed “fcitx” some year later. It’s never an input method framework, but an input method collection.

In 2007, there is some incident for Fcitx, you can find the detailed link on wikipedia. At that time I didn’t even use Linux yet. The story for me on Fcitx began with that I became a KDE user. At that time, IBus nor Scim is not a good choice for Qt based program, so I moved to Fcitx, and found there is a little plasmoid, called kimpanel. Fcitx’s kimpanel support is only a branch inside fcitx, and didn’t sync with trunk for a long time. So I decided to port it to the trunk. That‘s the chance that I become a Fcitx developer, till now. I want to make Fcitx a unique framework, which cannot be replaced. I carefully learn the all existing function of Fcitx, and I thought I finally found an awesome road for Fcitx.

Fcitx is famous of its lightweight, and quick speed, this idea didn’t chance even after I change Fcitx a lot. And it’s become even more light for the core, actually. Now I want to add some new properties to Fcitx, including native feeling, flexibility, and consistency.

Thanks to dbus, and kimpanel, I could make fcitx to use the most native UI on all the desktop, including GNOME, and KDE. And if you just want a xlib based UI? Ok, fcitx-ui-light is for you. And I even provides two configuration tool, for gtk users and KDE users, which could brings them the most native feeling on theirs system.

The second property is flexibility . Fcitx don’t choose the interprocess model, because that will breaks some flexibility of Fcitx. Input method is basically interprocess key stroke and mouse event passing between program. But I want input method can access some global property easily, and interact with each other, that’s why I stop my step for the interprocess input method support. Fcitx could be extended very easy, with nearly no limitation.

Consistency is the last property, which brings together with the first two properties. First, code is largely reused between input method, which brings consistency among different input method. The question about why this input method can customize punctuation, why that cannot, could hardly happen on Fcitx. Fcitx input method can share the built punctuation module, which also reduce the effort for developing an CJK input method. Other great features, like cloud-pinyin, auto switch, and quick phrase, are also shared among different input methods. This idea cannot be achieved by all existing input method framework.

What can be done with fcitx? Everything you can think of, for example, tweet sending could be extended to fcitx easily; bind a hotkey with specific input method could also be possible. You want a ncurses based configuration tool? Ok, just use fcitx-config to do the thing you want. Need some more dbus interface, fcitx-dbus is there and you can implement your own dbus module. I can hardly say there is some limitation to make your own input method module.

Feel free to join the development with Fcitx, to bring some more cool stuff to the input method world.