破坏性与创造性

我从 2010年1月15日给 fcitx 做了第一次提交，到现在也经过了不长不短的一段时间。选择fcitx的原因很简单，因为当初它在KDE下面没啥问题。

当然现在也是了。

选择fcitx是一个偶然的决定，不过至少到现在我没有觉得我的选择是错误的。

由于比较长的一段时间其实一直只有我一个人写代码，于是经常会出现一些巨大改动，大部分的时候都是当初写这段代码的时候考虑不足造成的。

破坏性的事情其实我没少干，ABI和API的兼容其实是我后来才学到的东西，比如说有些事情也是才学会的（struct的padding），不过学习这些的过程也很有意思。这两年来，写的最多的代码就是C的代码了（除了fcitx之外的代码也大部分是C的）。虽然说我写过的Code，按语言算也有一些，不过还是对C的代码最有感情。每每在深夜里面，写出的每一段fcitx的代码都让我心情愉悦。近期宿舍的人有去面试，回来提到的一些问题我比较容易就回答出来了，其实都是开发fcitx过程中学习到的 🙂

其实我是个很爱操心的人，操心这个操心那个。开发fcitx的时候，经常会因为某个功能不知道如何实现而辗转反侧，因为某个引入的bug而总想急切的发布下个修复了这个bug的版本。（当然还经常操心混蛋的GNOME又要把fcitx怎么样了，我讨厌GNOME的原因全是因为fcitx）

对所有使用fcitx的人来说，从3.6到现在的4.1.2，应该也经历了不少的功能变化。在这期间我不断破坏……比如说 GBK -> UTF-8，Xft->Cairo，配置文件格式以及布局的变化，引入DBus等等，其实我非常非常不想给你们带来麻烦，其实在你们没有看到的地方还是有一些向下兼容的事情，比如 ~/.config/fcitx 下面的拼音数据，现在其实在 ~/.config/fcitx/pinyin 下面，这里有个硬连接过去的操作，比如这个Issue，为了保持老的配置里面写了不少冗余的代码。

每一个向下兼容的操作背后都会意味着代码的膨胀，有个笑话是说“在我写这段代码的时候，只有上帝和我知道它在干什么，现在只有上帝知道了”。fcitx虽然是个历史悠久的项目（2002的gWubi 0.1），不过现在它还处于一个很年轻的阶段。由于我个人的水平限制，一些破坏性的事情是不可避免的（比如时不时的ABI就break需要重新编译下）……我非常感谢所有支持Fcitx用户。

为了避免你们的这种麻烦，建议不要手动编译，ppa，obs，官方软件源都是你们的好朋友。另外请尽量编译最新的稳定版，至少我会尽量做到提示而不是crash（比如fcitx内置的ABI检测和so version bump）。

其实到目前为止，我还没有来得及在fcitx创造什么呢，老实说我不是一个有什么创造性的人，不过目前还是有一些有意思的想法想要在fcitx上实现（这个想法倒是短期内难以实现的……希望libpinyin大能把多词库支持做好）。希望fcitx能坚持到那一天呢 🙂

顺便一提下面的计划。这次的两个部分都不是我孤军奋战了哦 🙂

非常感谢 ELizabeth HONG：名字已经解释了内容了，不过才刚刚起步，不要尝试（啥都没有呢还） https://github.com/fcitx/fcitx-anthy/

Raven Dark：（通过DBus开发输入法的支持） http://code.google.com/p/fcitx/source/browse/?name=dbus-bridge

非常感谢二位忍耐我的啰嗦，唠叨，不讲道理，非常感谢。

另外有些朋友问到的移植问题，最主要的问题就是人员以及设备（设备还在其次……），近期可能我就会入手N9一台，看看能不能在上面搞出点什么来（原生程序比Android的JNI，或者是iOS的ObjC要简单多了，更别提我不会ObjC了），当然我觉得也没啥人会去玩N9啦，不过给Plasma Active做输入法我还是有着相当的兴趣的呢，而且在我看来水已经在那里了 🙂