今天突然想到，fcitx是不能支持一个用户启动多个客户端的。
为了GTK_IM_MODULE，为了多客户端，似乎有种多进程架构势在必行的感觉。
这事不是不能做，但是似乎有种渐行渐远的感觉。
到底fcitx的特色是什么，我们要坚持什么？
当初死也不肯依赖glib，结果最后为了pango还是妥协了，毕竟重复发明轮子更让人痛恨一些（而且是这么巨大的轮子）。
总而言之，走上scim和ibus路吗？
想起一个人说，scim的前端后端很复杂，前些日子看scim的文档，真的挺有意思的，那个跨越计算机提供输入法服务的结构。对于最终用户来说，到底什么更重要呢？
其实说到这些我又再次想大抽linux的输入法架构，XIM也许也并不是一个很好的注意，但是像im module这种更加不是。
怎么办才好呢。
fcitx其实非常有意思，同时有xim，socket，dbus三个方式。另外如果有一天不用x了，xim又要呆在哪里呢，早做打算吧。
不用X？少说等10年吧……
fcitx的特色……难道是“方便”么？
不用10年。
如果三年后ubuntu用上了wayland，让ubuntu用户用不了fcitx？
不过nvidia很happy的成为了阻力，我很满意。但是fcitx的接口依然不够抽象。
不是不够抽象，而是过于不抽象了……当然这是高效的代价。
关于Wayland，其实我是第一次听说（除了看clutter新闻时候的一句话），所以刚才查了查相关资料……GTK3目前在转向中，但是不知道Qt会做啥反应。而且貌似窗口管理方面要有一些修改。
个人觉得ubuntu行事还是相对保守的（因为它是Canonical的唯一系统而不像fedora一样是个试验场），等它用上wayland了其他发行版也基本都用上了。到时候……至少dbus还是应该可用的吧？所以我觉得应该不用太着急……
qt有qt-mac，qt-x11，qt-win，没什么不好改的，这就是抽象的好处。抽象也不代表低效，相反代表这扩展性的极大降低。
dbus没关系，dbus甚至没有图形界面都能用的。
我现在已经打定注意不碰输入法算法这部分了，反正他们搞libpinyin到时候调用就好。一方面是好好重构fcitx的代码，一方面是多写几个wrapper。fcitx-anthy是下一个目标。
Intel 的 MeeGo Touch 用 wayland，meego用qt，现在搞qt-wayland的就是wayland 作者，看提交的id http://gitorious.org/~krh/qt/qt-wayland ，他是intel雇员。
1. 不管wayland会不会流行, fcitx都应该做好准备, 万一没有X了, fcitx用不了了, 那不是很郁闷. 不要相信nvidia这样的公司, 他们永远是用利益来评价一件事情的, 如果wayland变成了一个方向, 它不会不支持, wayland对嵌入式系统有很大的吸引力, 光这一点, 很可能让它发扬光大. 当然我们希望fcitx能用在更多的地方.
2. 加入glib这样的依赖并没有什么不好, 因为glib已经相当的成熟和稳定, qt都已经用上, 没有道理不用而自己再搞一套, 而且这些库是个发行版都有. 用户一半都已经安装了, 也不会有什么问题. 依赖多一点, 并不一定运行的就慢. 只要跑起来快就行了.
3. fcitx作为一个只输入中文的输入法, 我觉得是很成功的, 而且希望能保持只输入中文, 支持输入别的语言的需求是肯定存在的, 但是比例估计也是很小的, scim也好, ibus也好, 架构都做的太大了, 号称支持这, 支持那, 可是他们的问题和他们的特性一样多. 我们需要的不是这样的所谓先进的架构, 我们需要的是好用的软件. 总的来说就是: 高效(反应快), 稳定, 舒服的输入体验. 高效和稳定fcitx都做的很好, 但是用户体验方面还是可以有很大的提高, 非常高兴看到4.0的版本中加入了很多新的东西, 比如提供了菜单的功能, 不需要我再去找配置文件了, 很赞! 希望在细节方面能有更多的改进. 而不是做一个大而全的却又不好用的号称架构很好的那么个东东.
4. 输入法协议, 能实现的就尝试实现, 为了将来打基础.
fcitx应该坚持什么? 个人觉得应该站在用户的角度来思考这个问题, 我的答案是:
fcitx: 高效, 稳定, 好用.
我倒觉得支持多国输入法没什么问题，只是个wrap而已。输入法具体怎么样或者说有可能出什么问题还是要靠开发者本人。如果说“保持只输入中文”似乎有点不求进步的味道。毕竟有时候输入个其他什么语言或者输入什么特殊符号/符号组都是很正常的。