fcitx从诞生至今，代码中没有定义一个“候选词”的概念。
同时也没有定义一个“预编辑字符串”的概念（这其实也是fcitx目前不可能实现OnTheSpot的根本原因，虽然我觉得OnTheSpot带来不了什么太多好处，不过不知道为何那些天杀的程序都喜欢和OverTheSpot过不去……）
在提供给界面显示的时候，提供的是两个包含需要显示文本的数组，分别对应候选框的上半文本和下半文本。
现在这个设计终于要成为继续开发的阻碍了。
目前遇到的一个需求就是插入额外候选词，其实关于这点我也想了一些其他办法，比如说单独独立出来显示，或者附加在原有的列表后。（其实单独列出一条，然后用比如`这种键选择对我来说真的没什么大不了的……）
但实际上都为实现带来了不必要的麻烦。
于是决定还是添加候选词的抽象部分。
不知道怎么样改进下比较好。
现在调用的sogou，fcitx已有的三个拼音输入都可以用上，显示云输入法的第一个候选词。
虽然说加入了一个cache机制，不过究竟是我这里网速太快呢，还是怎么样，目前这个刷新速度还是稍微有点难以接受。
总归原理上已经实现了。需要个更好的展示方法。
感谢 @pipitu 回答我关于 curl 的问题。
KDE 的配置工具（至少完成了60%）（Done）
GTK 重新修过的配置工具（懒得动……现在的可以用，但是界面超级渣）（Done）
GNOME-Shell 的界面支持。（也是懒得动，呼唤gnome用户）
云输入法。（最近很想写的一个东西）（Done）
英文补全（Aron 希望我实现的一个东西）
fbterm 支持（也有点懒得动，不过应该相对容易才是，可以利用现有的dbus接口）（Done）
Python支持。
不想一口气吃个胖子的话，还是有所选择的更好。
有兴趣的人可以联系我。或者直接联系邮件列表就好。
短时间内被轮回系的剧情不断轰炸。
给你一次后悔的机会，你会去做什么呢？
即使失败，无数次的失败并不是没有意义的。
他们都会铺向最终的道路。
我很容易被那种执着感动。
有朋友在鸟嘀咕上要求我解释一下，我觉得简单来讲是解释不清楚的，所以打算写篇blog回复。
从功能上来说，它提供了程序之间互相交互的一个简单接口，程序可以尽量不关心关于底层的通信细节，而方便地和其他程序进行通信。它不仅仅在Linux和UNIX上实现了，同时也有Windows的移植版本（KDE4的Windows版就有用到）。
它对于底层的通信协议进行了封装，提供了相应的基本数据类型，简化了对于序列化的繁复操作，开发者只需要关心对应的操作即可。
从基础概念来说，一个程序会注册至少一个Service，这个service可以是一个公共的名称（这样的话就是一个面向开放的Service，期待其他人主动调用。）这个名称可以设置为互斥的，或者是可以无缝地由其他程序进行接管。或者不使用一个公共的名称，这样一般就是作为一个client。
每个Service下面有多个Object，每个Object可能实现多个interface，interface里面定义的是这个Object的属性（property），方法（method），或者信号（signal）。通过一个xml文件定义。对于一个object来说，它有义务实现org.desktop.DBus.Introspectable接口，别的dbus程序就可以通过调用这个接口的Introspect方法询问你对于接口的支持情况。
dbus里面的方法就像是一般的ipc/rpc调用一样，有参数，返回值。可以call给某个service的某个object的某个method。这一般可以用于dbus内的client和逻辑上的server进行通信（因为实际上dbus是使用一个daemon的形式运行，中间由他进行转发）。signal的概念可以认为是一种广播的机制，其他的dbus service可以选择按照某个filter监听signal，在signal触发的时候进行对应的处理。property则有它对应的get，set，以及在改变的时候触发标准的org.freedesktop.DBus.Properties.PropertiesChanged signal。
对于Glib，Qt，Python等等库，都有对dbus按照它进行抽象和封装，例如对于Qt来说，就可以将method和slot联系起来，signal和qt的signal联系起来，object就可以作为一个实际的“QObject”。通过qdbusxml2cpp这个命令生成对应的c++代码。
dbus上也提供了非常多的工具进行调试或者是命令访问，例如可以通过dbus-moniter监控某个channel上的dbus通信，或者直接使用dbus-send发送dbus的消息。qdbusviewer则是提供了一个可视化的界面，可以查看session和system两个channel的dbus操作。
dbus本身也是一个依赖非常轻量的库，除了一个xmlparser之外，就只有对应平台上的一些库。
如果想要通过dbus的底层api实现一个dbus程序（比如fcitx这样的），一般而言有两种简单的方法。
一个是在获得可用的dbus_connection之后，通过dbus_connection_read_write 直接一条条地处理dbus message（前面的method，signal其实都是一种dbus message），或者实现一个main loop，并且通过dbus_connection_set_watch_functions 注册一些函数，用来监视实际的dbus操作的fd，然后或者通过select，或者使用libevent，libev，在确认有dbus的消息到来后调用 dbus_watch_handle 和 dbus_connection_dispatch 处理消息。（实际上glib等库中就是这样实现的）
D-Bus 本身大大简化了不同程序之间通信的开发，并且稳定性也已经接受了多年的检验，对于开发一个需要通信桌面程序来说是一个很好的选择，并且也已经有无数程序选择了dbus作为它开放的接口，比如媒体播放器就有mpris接口来监控或者操作播发器的状态。
