Re-ask: Why Fcitx?

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.

This entry was posted in fcitx development and tagged . Bookmark the permalink.

11 Responses to Re-ask: Why Fcitx?

  1. justin wong says:
    Android Webkit 4.0 HTC Vision

    看起來好吸引開發者的樣子~
    p.s. 話說好多 動詞 單複數的bug啊!

  2. 右京样一 says:
    Firefox 9.0.1 GNU/Linux

    CSSlayer咋最近开始用英文写了,莫非是为出国作打算了?

    我觉得要总结起来有这几个理由把:
    Fcitx开发者虽然很少(也许太少了),但很活跃。
    Fcitx已经是一个输入法前端了。反过来想,ibus、SCIM提供了什么独一无二的功能让我选择它们吗?
    Fcitx没有明显的桌面环境倾向。对于我这样的KDE用户来说,Fcitx也能提供很好的体验。
    Fcitx提供了优雅的图形方式来进行配置,而不是要用户先去了解配置文件然后钻进去手动修改。我有图形界面癖。
    Fcitx的高度扩展性催生了很多有趣的功能,例如手写、虚拟键盘之类。虽然暂时还远谈不上实用,然而一旦有必要时,这些凭个人兴趣开发出的东西都可以作为很好的参考。新设备的推出决定未来的输入法前端不可能在“单一平台、物理键盘”这一棵树上吊死。扩展性越高,未来道路的阻碍就越小。

  3. litkt says:
    IceWeasel 9.0.1 GNU/Linux

    图形方式和文本配置文件的对用户的区别就是点选与不点选还是写Ture还是Falsh及其与此类似的区别,点选还是不点选、Ture还是False还是要看文字提示的。可能有人认为无法做到多种文本并存以应对不同的编码环境,实际可以,提示文字可以把英文、GB2312汉字和UTF-8汉字放在一块的,无非打开的时候总能恰好有一行汉字不是乱码。

  4. litkt says:
    IceWeasel 9.0.1 GNU/Linux

    true

  5. csslayer says:
    Firefox 9.0.1 GNU/Linux x64

    @litkt GB2312 makes no sense on linux.

  6. 清风 says:
    Firefox 9.0 GNU/Linux

    这是我第一次耐着性子看完一篇全英文的文章,虽然有些还看不太明白,也理解的不太清楚,但有些想法:
    1、真希望这么好的输入法能继续开发下去,成为linux环境下国人的骄傲;
    2、用linux也有几年了,原来也试过fcitx,就是配置的繁琐让我望而却步,虽然这是linux下的理念,现在好了,图形界面设置很好;
    3、没有明显的桌面环境倾向,这一点不错。但现在不少开发者也在尽力做着不同桌面环境软件的融合工作,kde下使用gtk软件也不再丑陋,oxygen-gtk不就是吗?做两个不同的qt和gtk界面是不是花费一定的精力?如果不费什么事的话还行,如果太费力,个人感觉还是尽量不要把许多精力放在这上面了。

  7. csslayer says:
    Firefox 9.0.1 GNU/Linux x64

    @清风 从最开始的配置设计就是把配置项和界面实现的逻辑分离的,这个想法最初是参照compiz设计的。总之还好,界面写完一次基本不用写第二次,除了如果要扩展新的类型的值之外。具体细节你看 /usr/share/fcitx/configdesc 就知道了,那个里面的文件用来描述配置本身的。

  8. litkt says:
    IceWeasel 9.0.1 GNU/Linux

    @csslayer
    GB18030环境一样的。
    我说的意思是,只要不在乎有一行乱码,改配置文件用文本提示还是用图形工具,方便程度是一样的。

  9. lun says:
    Firefox 11.0 GNU/Linux

    个人感觉,fcitx没有小小输入法好用。在我的笔记本上,fcitx明显比小小输入法慢。在台式机上没有那么明显。

  10. litkt says:
    IceWeasel 10.0.2 GNU/Linux

    @lun
    如果把五笔设成精确匹配,在低档机上Fctix的速度会有显著提升。
    这是我在我的老的K6 400MHz/192M内存笔记本上发现的。现在换成了P3 600MHz/256M内存的笔记本,就不再有速度问题了。

  11. lun says:
    Firefox 11.0 GNU/Linux

    @litkt
    嗯~ 以后如果再用到 就试一试~ 五笔用户对输入法功能需求不多~~ 嘿嘿

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.