人的一生能有多少个 14 年？
开端（2009）
commit 95f13144a52d409da387af4f1a25aa01bc6bb653
Author: Weng Xuetian <wengxt@gmail.com>
Date: Sat Jan 16 06:17:12 2010 +0000
Add Kimpanel Support
这可能是一切的开始。其实最早给 Fcitx 的贡献，就是 3.6.3rc 之后给 Fcitx 增加 Kimpanel 的支持。2008 年 KDE 4 刚刚发布，之后因为一些偶然的契机，发现有人为了 KDE 界面的集成，为 KDE 和 Fcitx（也包括scim 和 ibus）增加了一个基于 DBus 的面板协议。当时 Fcitx 的相关的代码因为 Fcitx 并没有一个插件架构，因此是保存在其中的一个分支当中的。
当年的这个时刻我竟然也写了博客记录，当我找到它的时候，它夹在两篇略羞耻恋爱感想的中间……
当我发现记录一切缘起这篇博客是在 102 页的时候我也是吃惊不小的。
Fcitx-dbus-svn ON AUR
Posted on October 25, 2009 by csslayer
由于我现在一直使用KDE桌面，某日曾经发现了个好东西：kimpanel
这个Plasmoid帮助Plasma和linux当中的输入法实现了一个统一的界面，目前linux下面流行的三个输入法fcitx, scim, ibus都由作者实现了一个后端。由于某些原因，Fcitx界面和程序是不分离的，因此只能用修改源码的方式使其支持kimpanel。kimpanel通过dbus和输入发进行交互活动，从而完成界面的统一。
fcitx-dbus的原作者貌似很久都没有维护了，因为最近fcitx修改了大量的bug，因此原有的fcitx-dbus还保留着这些bug……由于Archlinux的AUR上的fcitx-dbus-svn的包是我打的，因此我把我的port给放到AUR上了……原作者和各位用户不要伤心啊……？
貌似kimpanel还有一些问题，和fcitx的支持不是那么好，因此我（就算是为了我自己）也修改了一部分的bug……
跑去fcitx的issue发了个贴，暂时没人理我……又和fcitx-dbus的作者发了个信……也没理我……囧
总而言之，我就莫名地接手了这个项目的 fcitx 的部分，然后谁也不知道这埋下了一颗怎样的种子……关于我这一年的当时的生活……和我现在的老婆谈恋爱一年多了。大四刚刚开始的样子。
不断的维护和第一次大版本的飞跃（2010）
总的来说，这部分时间的提交历史我意外发现了一个历史悠久的噩梦，就是托盘图标。这部分如果展开讲的话，会涉及太多太多技术的细节，不过这时我回顾起来我才发现，我大概是真的不懂完全在盲人摸象一般修复那个托盘的透明问题。这个问题可能乃至到了 Fcitx 5 的时代仿佛鬼魅一般归来过……
但总之这也是给 Fcitx 开发代码的一个侧面，由于依赖的精简和 Toolkit 的缺位，很多基础的功能都是从更加底层缺少文档的协议实现起的。想象一下，在 Qt 中只需要 new 一下就可以创建的托盘图标，在 Fcitx 5 中却有 1.5k 的代码，实现了两种完全不同的方式…Toolkit 实在是替你负重前行了太多。
第一个大版本究竟是为了什么呢？现在的我可以说也是记忆模糊了。但那时我维护了一个内码是从 gbk 转到 utf8 的分支。在 3.6.4 的发布之后它也合并到了主干上。一方面，从这里的提交文件可以看出，这里为了当初 Fcitx 停止开发的其中两个原因「中文配置文件」和「用GB存储数据」以我个人的想法进行了修改……这里用描述型文件来生成界面的想法已经初具雏形……不过即使到了 Fcitx 5 的时代，Fcitx 3 的中文码表格式也依然可以兼容使用……但因为 dbus 强行要求 utf8 编码字符串，因此将整个内核转换成 utf8 其实也是一种势在必行的修改。
另一方面 fcitx-utf8 分支的重要功能之一……皮肤支持也不得不引入了更多的依赖，为了加载 png 文件而使用了 cairo。这里我还记得因为使用 cairo 而相关的字体问题。cairo 的文字绘制是没有 fallback 功能的，所以我又不得不引入了更高级的文字排版库 pango。
时隔一年之后，终于 Fcitx 到达了 4.0-rc1，回顾当年的发布公告，很多现在保留的功能也都是在整个版本发布的，例如搜狗词库转换。
另外里面的一个功能就是输入法可以由插件加载了，虽然只有 sunpinyin，但是也是可扩展性方面迈出的一大步。
https://groups.google.com/g/fcitx-announce/c/BBueYZSRXiY
* 皮肤支持，采用cairo做绘制，pango负责字体，界面支持真透明；
* 拼音支持多个词库：利用createPYMB创建的词库放在~/.config/fcitx/pinyin下面即可；
* 额外的输入法支持（目前只有fcitx-sunpinyin）；
* 基于gtk的图形配置工具fcitx-config（并不包含在fcitx源码包中）；
* 右键的菜单支持。
配置界面采用 gtk 其实在当初也是仔细思考过的……就像前几个月的 libime 用个 boost 都有人 BB 半天的事情。
在这个时期，每一个额外依赖的引入我都是和自己内心做了巨大的斗争的。
第一次大重构（2011）
4.0 没有几个小版本号，我就开始思考 4.1 要进行大规模的重构的事情了……一方面，同时存在的两套界面，多个输入法也让那时的代码开始有点承受不住发展的方向了。从 4.0 到 4.1 有好几个大变化，一个是沿用至今的插件架构，另一个就是构建系统从 autotools 转到了 cmake。
autotools 的并行编译手写实在是很容易出问题……和语法更加清晰的 cmake 相比差的很远。我还记得那一段时间我花了很长的时间构思这个虽然现在看起来还十分不成熟的架构，我从学校的角落的门走出去去买肯德基的时候还在边走边思考。
最终我拿出来的方案就是一切功能皆插件，以及一个插件间互相调用避免链接的依赖关系网。
Why fcitx need refactor?
这里 GNOME 已经给了 fcitx 第一个闷棍，就是输入法界面不能显示于 gnome shell 界面上方。当然当初我也并没有觉得什么。不过也为了后来的一些事情埋下了种子……
为了解决 GTK 的问题我也实现了 im module。我还记得和 sunpinyin 的一个开发者在 bugzilla.gnome.org 上为他们的 xim 支持问题争论的事情（sunpinyin 有一个纯 xim 实现 xsunpinyin）。im module 其实在当初也是被逼上梁山的产物，因为还有 xim 在 firefox 中的坐标 bug 也是有十余年历史才修复了一半？
毕业，和 GNOME 的仇怨，和迷茫（2011-2012）
在这一年发生了很多事情，一方面，生活上毕业，申请学校，和被迫干不想干的事情的迷茫困扰着我。我其实早在这一年大概就意识到，我不是一个喜欢学术研究的人。我喜欢的是工程方面的工作，从小当我第一次玩到 LEGO 的时候，我就觉醒了这种构建积木的快乐。
但是女朋友毕竟已经出国了，虽然想来我多少骨子里是一个很被动的人，在很多事情上都被生活推着走。那会儿也没有想明白，出国了之后能干什么。
另一件事就是 GNOME 3.6 集成 ibus 给我巨大的打击。基本上，从我刚接触开源软件开始，就有那么一些幻想的滤镜，大家是友好的，是想要一起做成什么事情的幻觉。
https://www.csslayer.info/wordpress/kde/fcitx-kde/
https://www.csslayer.info/wordpress/fcitx-dev/why-gtk-apps-are-likely-to-suck-on-input-method/
我得承认我是迷茫了很久，从 https://www.csslayer.info/wordpress/fcitx-dev/why-fcitx/ 一直到 https://www.csslayer.info/wordpress/fcitx-dev/re-ask-why-fcitx/ 。
我还能记得在夜晚学校的公交车上因为 GNOME 而气到胸闷的时候（这件事是在我留学的学校），所以真的，我头一次对我投入这么多感情给 Fcitx 而感到后悔。
但总而言之，后来的故事就是我硬生生是被 GNOME 逼出了逆反心理。
「凡高大者，我无不蔑视。」
生活的问题，孩子的出生，和逃避现实（2012-2016）
前面我也说过了，我在生活的很多问题上其实都没有认真的思考过，而且我还是那种不知道放手的人。就像我不肯放手 Fcitx 那样。其实回过头来看，很多事情也许放手会变的很不一样，例如我应该早点 Quit PhD。
2013 年我结婚了，但是学校方面的生活也没有因此而步上正轨，研究生最后一年的自我堕落终于还是找上了我。在留学之前我想的其实很好，尽管申请学校方面是靠了很多的贵人的相助，但是那会儿我幻想着还是能够抛弃因为提不起劲头而感到一事无成的自己从头开始。
然而事情显然并没有这么好。
当你给你自己找到一个借口的时候，例如孩子的出生，就更难以继续那些原本就不想做的事情。然而不想要放手的优柔寡断又开始不停的作祟，导致陷入了「我还想试一下」，「但是我的身体只想要摆烂」这样奇怪的死循环中。
如果继续说下去似乎和 Fcitx 就没多大关系了，这段时间 Yichao Yu 写了很多的功能，有许多我其实至今都没有仔细看和了解过，例如著名自检脚本 fcitx diagnose 就基本上完全来自他的手笔，里面 shell script 的花活至今我几乎从没认真研究过。
然后，就是你写得越多，迷茫就越多。当你积累的经验增长到一定程度的时候，就会回头发现从 Fcitx 3 时代起缝缝补补的马车已经很难承担更多的任务了。而且还是自己在那个青涩时代写出来的代码，充斥着大量脑袋一热的设计和经验不足而留下的难以扩展的问题。
想要推倒重来的念头在 2013 年就产生了，而其结果也就是夭折的 https://github.com/fcitx/fcitx-ng/ 。当你坚持想用 C 写些什么的时候，语言本身的负担就越来越沉重，终于到自己也再也推不动的时候，也是借着 C++1x 的东风，想要试一试全新的 C++ 的体验。然后终于有了 Fcitx 5 开端。
Fcitx 5 – 缓慢而全新的开始（2017-2020）
直到 2016 年年中，它才开始短暂的恢复活力。毕竟自己的第一孩子已经半岁，偷闲摸鱼的时间也算增长了不少。因为 fcitx 5 而诞生的项目有三个，xcb-imdkit，fcitx5，libime。xcb-imdkit 完成的最早，然后 fcitx5 和 libime 同时推进。Fcitx 5 因为 kdbus 的东风而决定尝试用 sd-bus 作为 dbus 实现 sd event 作为 event loop，不过后来又加回了 libevent（最新的 master 换为了 libuv） + libdbus。
拼音的首个里程碑大概是 2017 年 4 月，然后 2017 年 10 月左右大概有了最初的新码表。之后大概就是不断的 dog fooding，以及不断吸引到有人来测试。我和我自己定下的约定就是不能比 Fcitx 4 缺少什么功能，因此最后的时光大概就是移植，移植再移植。
快车道和新的伙伴们（2020-2023）
在 Fcitx 5 发布一年之后我也写过一个记录 https://www.csslayer.info/wordpress/fcitx-dev/one-year-in-fcitx-5/ 那里就已经提到了 android 移植。虽然可能也是某人头脑一热的决定，不过到现在也变得更加完善，参与的人也变多了不少。
然后就是 open kylin 的虚拟键盘作为去年最重要的功能更新之一。现在还有人正在进行 mac 的移植工作。对我自己来说我最大的成就大概是 libime 新模型的训练吧……这个是货真价实因为数据量级的问题，而不得不使用钞能力来解决的。
所幸这个最后的结果是我很满意的，现在我就在用着 Fcitx 来输入这篇博客。我对于它预测准确度可以说是相当满意的。
未来是？
还有很多工作需要完成，不过感觉也已经渡过了最难的时候。在去年年初的时候我家庭成员的数量又翻了一倍，但我也没有以前那么焦虑了。虽然我自己的未来还有很多不确定，但 Fcitx 的未来至少在许多朋友的帮助下又打开了更多的可能性的门。
时钟已经指向 1：30，虽然我感觉有许多话想要讲出来，但是也总是在这种时候才能感受到自己语言方面才能的匮乏。
若要问我有什么想法…大概感觉就是他已经是我生活的一部分。
至于关于技术上的体会，有机会再聊吧。
不快乐的，终将过去，快乐的，总会留下。在不远的未来再见吧。
