好吧，离4.0发布虽然还没多久，来考虑一些新问题。
最重要的就是承诺过的fcitx的gtk im module，以及更多的rework。
众所周知，fcitx有这样那样的问题，gtk水土不服啦，只能单实例运行啦，输入效果差啦等等。
我以前说过，我主要的精力还是放在整体的framework上，而不会花太多精力在输入法本身上。所以这次的工作主要就是解决和其他程序的兼容性问题和代码的重构。
fcitx的issue列表不能说很短了，扫过去的话，其实很多都是和gtk im module相关的。
为什么不是xim，我个人认为有两个很简单的原因，其一当然是现实所迫，那么多的程序没有gtk im module就不能正常工作，不幸这个只能从fcitx做起。另外一点，就是xim离开x还能运行吗？因此gtk im module当然有它存在的意义。
另外一方面就是把fcitx完全的拆散，everything work seperately，everything works well，现在关于这方面的点子在我脑子中一个接一个的冒出来，我都有些心潮澎湃了……
比如软键盘真的应该集成到fcitx内部吗？似乎没有必要。quickphrase也是。如果剔除之后他们能不能和原来的功能一起工作？如何一起工作？都是一些有意思的问题。fcitx的core最后应该剩下什么？坚持不依赖ui toolkit的fcitx是不是应该提供一些简单的ui toolkit机制让其他功能也可以开发自己的ui？
希望4.1出现的时候（按照我的速度以及精力……汗，这点还是异常值得吐槽的）能够对于fcitx的本身带来一些革命性的变化。
虽然不知道最后说点什么好，结语是，希望有一天fcitx能够走到所有平台上，就这样吧。
P.S.
由于时间原因，我个人是不倾向于定时间表的，啊，虽然我很乐意干这件事情，但是还是有很多其他有意思/意义事情想做，被自己的兴趣赶着屁股走不是啥好事，反而会失掉热情。
那么还是只列一个计划表吧，按照这个计划表慢慢往下走。
1、将所有ui部分抽象，实现一些event driven的接口。
2、将和其他程序交互的部分抽象（xim，immodule），初步计划用socket重写这部分。话说最近阅读的一个代码也给了我启发，虽然仅仅用telnet做协议，但是很简单，而且工作的很好。
3、把内置的两个输入法（拼音，码表）也提取出来，作为模块。
4、增加其他milestone上的new feature
5、test again and again
6、4.1就到此吧 🙂
果然是换主题了。有没有想过把这个输入框也弄成透明的？
哪有换主题 XD
换个背景而已。
对于技术性的东西我实在是不懂啥……所以只能扯点没啥技术含量的周边话题了。
//
话说我一直有个问题……如果换用GTK im module，那么“Fcitx”的“X”是什么意思呢？还是说要像Intel或者HTC一样换全名不换简称？不过话说回来，如果真用GTK im module，那必定是个“革命性的变化”……不知道绘制上会不会变慢？
另外我支持“一切皆插件”的想法。不过不知道这样的话会不会给新手带来一些麻烦。如果像Eclipse一样能有一个大集成包就最好了。
不过也有隐忧。如果“一切皆插件”，那么Fcitx core最后必定会变成一个“输入法平台”，会更接近ibus（甚至和它功能重叠）。如果不是完全分成模块（比如像软键盘这样的功能不剥离），大概就是个更“有苹果味”的输入法平台，输入法开发者只需要把算法搞好，其他的一切（比如通信）由我core接管。
被自己的兴趣赶着屁股走不是啥好事 +1。我现在就觉得生物没以前那么有趣了。
gtk im module 和绘制一点关系也没有……（如果单论绘制的话）
至于名字这种事情……什么都无所谓啦。（这年头很多software在经历了大变化之后直接把缩写的意思改掉了，想必将来能想出个好缩写，万一fcitx将来也有不少国际化输入了……C怎么解释也是问题啊。emacs的缩写代表含义其实巨多，虽然不乏很多是恶搞的……）
算啥隐忧……另外我就是大踏步的往这个方向drive呢你没看出来嘛……有意见了叛逃了就好嘛，或者坚持老版本啰。
我倒是没意见。但如果这么说的话Fcitx的哲学到底是啥呢？当初做皮肤的时候小企鹅都不能去掉。现在却连Fcitx的哲学是什么都不清晰了。
啊，另外你对gtk im module是不是有什么误解……没太搞清楚它的地位？
另外也不见得有啥哲学吧。老实说以前界面上也没小企鹅不是吗。我也就是不想换logo呢……
我希望fcitx更具扩展性，无论从任何功能上来说都具有强大的扩展性。我希望fcitx易于移植，不论是wayland还是xserver，不论是win还是linux还是mac还是别的什么。我希望fcitx可以支持很多输入法。我希望fcitx可以支持除了c语言之外的其他语言开发。我希望fcitx可以从各种意义上支持只要是键盘输入一段字符之后就要干的事。为了这一切的目的，fcitx需要作出什么样的变化，具体就参考原文吧。
再说我的每一步其实是在代码大变的情况下尽量让原有功能没有很大变化。如果换到classic之后，和以前的用起来有很大差别吗？其实不管怎么样，我已经尽量保证小企鹅用起来还是当年的那只小企鹅啦。
看了一下GTK im module的相关介绍，大部分没看懂……不过发现以前确实是有误解。不过既然如此了……干脆把绘制也交给高级库解决？
另外貌似还有个immodule-qt？那个有人用过不？
……后半句你就饶了我吧。不过以后界面分离之后也可以写个吧。
qt-immodule当然有人用,比如ibus-qt
因为ibus最近在chromium下出问题了，开始用起了fcitx，源里的4.0.0-1，感觉挺好的~
报个bug，在我电脑上用fcitx打“时间充裕”这四个字会崩溃，fcitx版本为4.0.0正式版。
回楼上，我这里“时间充裕”一切正常……
提供下~/.config/fcitx/crash.log吧。
最近好像崩溃的有点厉害了，我的另一台电脑打“时间充裕”也没问题，都装的是Ubuntu 10.04，版本也都是4.0.0
地址： http://is.gd/ibZOf
我是楼上的，我发现fcitx装了sunpinyin以后就不再崩溃了。可见我系统是和fcitx的拼音不兼容，而不是和fcitx本身。
@bachue 大概是拼音词库某日被写坏了…
为了用tinycore找了几天的输入法，只有fcitx4最好用，第一次就编译成功了，而且使用一切正常。
xsunpinyin 编译也很顺利但使用有时莫名其妙的缺图标，而且不能退出每次改双拼码表都要手动kill。配置工具只能通过系统托盘里的右键菜单访问。。。
小小的一坨文件都堆在一个文件夹里打包困难不说还依赖gtk2和glib2。
ibus 不显示输入条，那ibus-pinyin真不知到底有多少依赖关系。补了将近20个包还是不能编译通过。
只有fcitx最顺利了！加上sunpinyin引擎以后使用感受也不错。
真要感谢fcitx，换了这么多输入法只有fcitx是不依赖gtk2的。这些小系统上真的是很难得呀。