KDE 的配置工具（至少完成了60%）（Done）
GTK 重新修过的配置工具（懒得动……现在的可以用，但是界面超级渣）（Done）
GNOME-Shell 的界面支持。（也是懒得动，呼唤gnome用户）
云输入法。（最近很想写的一个东西）（Done）
英文补全（Aron 希望我实现的一个东西）
fbterm 支持（也有点懒得动，不过应该相对容易才是，可以利用现有的dbus接口）（Done）
Python支持。
不想一口气吃个胖子的话，还是有所选择的更好。
有兴趣的人可以联系我。或者直接联系邮件列表就好。
云输入法是要有服务器的，难道要“借用” Google 、搜狗、腾讯的服务器？
@vx13 哦，其实我说的意思其实是call那些服务。来更好支持拼音输入而已。倒不是说让fcitx本身成为云输入法（这个想法我也有过，不过感觉现阶段毫无意义）。
我想要德文补全，可以吗 ……
一口吃不下胖子，但口数太多会可能把FCITX本身给吃成胖子，就象ibus那样。
4.01版的输入是并行的吗？在速度慢的低档机上，五笔输入时，后输入的词竟然有时先上屏，导致词句颠三倒四。先把这个问题解决了再说别的吧。ibus再慢，五笔上词也是按输入顺序来的。(不过Debian Wheezy版的ibus的五笔输入条上的按钮一点，输入条就会崩溃，接下去就是完全“盲”打了)。
我没见过哪个德国人用英文或德文补全，全都老老实实用键盘敲全每一个字母，速度极快，行云流水。字母文字补全和汉字输入的联想选项的性质是一样的，干扰思维,降低速度,还无端增加系统资源开销，不是好主意。
应该以身作则多鼓励其他Project都向QT/KDE靠拢。gtk/gnome的东东懒的动就懒的动吧，忘了最好。
KCM支持和fbterm支持不错。一个人开发真是辛苦你了。本来我对这项开发也有些兴趣，无奈编程基础薄弱。
@litkt 4.0.1？……4.0.1会这样？……那真是意外。。。也从来没人汇报过这个bug，不过考虑到gtk im module现在已经实现，即使由于xim导致了这个问题，这应该也不再是问题。
或者那个就是你输入的程序本身的问题。
另外在读过源代码之前就不要评价臃肿还是不臃肿，因为这个说法毫无道理。
@litkt @csslayer 问题应该不是由输入法本身引起的。记得我老PC在OpenOffice里用ibus也有这问题。可能还是系统通讯方面的问题吧……
@litkt 关于你说的西方语不需要补全，当然作为母语使用者确实不需要。就像我们中国人说话基本上不会说一个词说一半然后跑去查字典，但是一个人把中文作为外语来使用，他可能记得这个词的一部分，这个时候他需要去查词典。这里也是同样道理。
不论字母文字是不是母语，单词补全都跟汉字的联想一样，绝对是个干扰。
至于是不是臃肿，看编译好的可执行文件尺寸也是一样的。到现在为止，FCITX还算轻巧。我只担心以后走Ibus的道路。
ibus臃肿吗？本身可能不，但加上那一大堆依赖就恐怖了。
作为最终用户，我只希望FCITX能象当年在80486的WIndows 95(英文版)上仍能运行如飞的南极星那样轻巧，而不是WindowsXP汉文版上的微软输入法那样臃肿。
@our1944
您所说的这种情况，需要的是拼写检查(Aspell/Ispell一类)，而不是英文/德文补全。补全是没必要的功能，不应为此加重Fcitx负担。
@litkt 英文补全到底有好还是没有好，从我个人的角度看当然是有好，但从来没人说这个功能不能关掉。
你的“臃肿”和我的“臃肿”和大家的“臃肿”很可能都不是一个意思。从代码的角度可以评价臃肿，从依赖的角度也可以评价臃肿。如果要我说，我最近的一次修改删掉了fcitx超过1k行很冗余的代码，那在你看来到底是臃肿还是不臃肿呢？
依赖多就一定慢吗？不一定。依赖少就一定快吗？也不一定。
如果以响应速度快作为标准的话，fcitx响应速度快和它依赖少没有多大关系。也就是因为fcitx将所有词库数据全部放进内存里面了而已。但这和ibus的依赖有什么关系？没什么关系。
这年头早就脱离了看依赖多少决定速度的年代了。评价速度快慢，也要先搞清楚到底慢在哪里。
@litkt 其实我见过自动补全的英文输入法……另外您真的认为英文补全没用吗？您写程序的时候不用自动补全吗？据我所知我的kate在编辑纯文本的时候也会根据上文的词列出自动补全条目……
另外Unix哲学里有一条是“测试代码。只有在你详细测试了代码，并且发现一部分代码耗费了绝大部分的运行时间时再对程序作速度优化。”
回右京：
为了回复你的似是而非的观点，我的FCITX和Iceweasel同时死锁了两次，二十多分钟浪费掉了，不由火往上撞，语言因而简单粗暴，请见谅。
Unix软件原则是保持简单，一个程序只做一件事，而不是先实现一堆有用没用的功能后，再优化资源消耗得不象话了的部分。
在字母文字世界从来就没有输入法(IME)的概念，输入法干脆只是为汉字圈而生的，那么英文输入法也应为汉字圈的画蛇添足之作，基中的单词补全功能让您老见到了，并不能证明这种功能就是有用的了。另您又把集成编程环境里的代码补全也扯进来，可代码补全和单词补全不一是回事，代码补全有用也不能证明单词补全就有用，自然语言的词尾语法变化会让单词补全变成讨厌的选词动作，倒不如拼写检查的自动更正提示来得利落。另代码补全既然已经在集成编程环境里实现了，还要在已经 压力很大的汉字输入法里再实现一遍干什么？可以出看，右京兄是会编程的，但不得不说您经常的概念混乱和奢侈习惯会使您编的软件摆脱不了臃肿和对俭朴计算机歧视之嫌，而这恰恰是Fcitx作为简体汉字输入必要的组件所极力应避免的。
回博主：
由于奔腾级的俭朴计算机不仅运算速度限有，内存和硬盘空间也有限，所以判断软件是否臃肿就不仅看速度一项了，几十M专有依赖的硬盘占用也不应该。Ibus有这个问题，好在Fcitx还没有这样，希望保持。
FCITX输入条提示中的文字调用频繁而迅速，但不必太美观，清晰醒目即可，而且字体大小固定，字数固定(最多GB18030-2000范围，少了可以，够码表用就行，多了也没用)，不包含阿拉伯字母一类变形需求(这是Pango的最重要功能)，所以FCITX没有必要依赖Pango/Cairo，连AA也不需要。与其依赖这些，倒不如强制使用点阵字体，依赖或自带一个合适大小的PCF点阵字库。把文泉驿点阵宋体中抽出一个打进Fcitx包里，哪怕用户装重了，也比依赖Cairo/Pango轻不是？自己掌握一个小的PCF点阵字体，就既可以摆脱一堆AA字体相关依赖，也不用重复发明处理用户复杂的字体环境的轮子了。
无论词语颠三倒四，还是死锁，不管问题出在Fcitx还是XIM还是Flash还是什么身上，只出现在低档计算机的高速输入过程中，中档以上计算机不发生问题，如果在俭朴机上输入的速度很慢，也不会发生问题。我想如果在输入条文字处理渲染这一块尽可能减少消耗，尽可能的轻，也会缓解在俭朴机上高速输入的颠倒或死锁问题吧。
一家之言，一孔之见，仅供参考。如果我说得不对，不理我就是了。如果我碰巧说对了，减轻渲染字体消耗可以部分缓解问题发生频率，就是不强制使用TTF/Cairo/AA/Pango，给低档机一个使用点阵字体的选项(不是编译选项，是Config选项)也是好的。
@litkt @litkt
什么配置的机器？哪个版本的fcitx？用的什么输入法？ ~/.config/fcitx/crash.log 有什么内容？（刚刚出问题的那个时候）
其实你说的原因到底是对还是不对这个完全不清楚。不过反正现在的架构换个界面什么的十分easy就是了。我可以有空fork一个界面出来。
我觉得还是依赖cairo的好。cairo利用GPU来分担CPU的工作。有人会说一个输入法讨论CPU资源是无病呻吟。我看来，CPU资源省一点是一点。
@litkt
你这么一说我也想起，我的老爷机上用Fcitx五笔也会遇到这种后输入的词先上屏的现象。。。
@litkt
在CPU占用率高加上打字快的情况下就会出现，尤其是文字和标点符号的顺序出错比较常见
@Enyh 其实你说的应该不正确，cairo在各大发行版应该是只有xrender后端，而不是glitz。
@litkt 另外补充一点，im module和dbus的使用对于改善xim带来的问题是有帮助的。
@beginner 除非是xim自己本身能乱序…（关于这点我并不确定）
不过如果如果用dbus的话，dbus消息本身是有serial的没跑的，应该不至于出现这个情况。
@csslayer 只是现状吧……
@Enyh 是现状就够了……我一般不对虚无缥缈的东西抱有希望。
@csslayer
Toshiba Satellite2100CDT 笔记本，CPU应为K6，192M内存，Debian Wheezy，IceWM(Gnome/KDE想都不要想)，LC_CTYPE=zh_CN.UTF-8, Fcitx 4.0.1-6 五笔，快速输入，输入条显示跟不上时会乱序，如果在Iceweasel的Flash里快速输入，输入条显示跟不上时经常会死锁。crash.log的内容是:0: X IO error.
以前用3.4.2预编译版五笔时，不会乱序，但Iceweasel死锁更频繁。
所以我仅从现象分析，认为输入条要处理提示信息时，要处理的东西越少越好，只要在落后的CPU上的反应也能跟上快速输入速度，就应该以可避免这现象。至于输入条上的内容转瞬即逝，好不好看并不重要，能看就行，不必AA等等。当然我的看法也不一定对。死锁应该怪Flash，但英德法俄阿拉伯文的XKB在Flash上都不出问题，唯XIM死锁，你也拿Adobe公司没办法不是？输入法没法轻到XKB的水平，也尽可能的轻吧。绕开XIM也是办法，只是别依赖KDE输入管理器。
@litkt
话说你的死锁到底是个什么现象？fcitx挂了吗？还是只有iceweasel抽了了？其他程序接下去如何？
如果fcitx没有挂的话 crash.log 就没什么可看的（你目前贴出的也就是个注销的时候会产生的正常信息而已）。在你的系统上，我个人认为内存和硬盘的影响远比CPU的影响要大。大概在你用iceweasel的时候swap早就多多的用上了吧。输入法和XKB从本质上说可差远了，因为需要单独一个输入法进程和X通信。
另外话说这和KDE有什么关系？输入法管理器和输入法协议完全就不是一个东西……目前你给我的感觉就是你还不完全清楚Linux下面输入法的工作方式，然后就下了一些结论。
首先是乱序输入这个问题，从原因的角度来讲，有几个可能，1，fcitx本身就按照错误的顺序提交了输入，2、程序错误地处理了提交的文本请求的顺序，3、在传输提交文本的请求过程中顺序发生了错误。
首先fcitx本质是一个单线程程序，因此1是不可能的。2和3都可能发生，也可能同时发生。从我个人的观点来看，最有可能的情况大概是XIM的提交是无法保证有序的，在实现上如果请求有递增的序号，那么程序自身的处理就完全有能力避免这个问题。当然如果这个现象仅仅发生在某特定的程序中，那么就应该怀疑这个程序是不是有问题了。
其次是锁死的问题。首先你没有完全描述清楚你的情况，从描述看来好像只有一个浏览器一个坏掉（当然你可能只开了这一个程序）。fcitx自己有没有挂掉也没有提到，那么就当作是fcitx没有挂掉好了。你的机器在目前的环境中，内存是相当小的系统了，而且你又运行了firefox这种很可能占用很多内存的程序，使得用上了swap，很有可能因为这些磁盘的io操作导致你的系统变得缓慢。XIM很坑爹的一点如果一个发给输入法的请求较长一段时间内无法得到回复，输入程序就有可能变成freeze的状态。而且即使杀掉输入法也无法恢复。
XIM的支持是实现在ui toolkit内的，gtk和qt有im module来支援xim，这个im module是可以换掉的，也就是说这里可以不采用XIM的协议而采用fcitx自己的协议，事实上ibus和scim都是这么做的，scim是用socket自己实现的，而ibus则是通过dbus实现的。fcitx这边也是采用dbus来实现这个协议的。当然dbus本质上也是socket。
好那么回到之前的问题上，dbus的消息是可以保证不乱序的，如果刚刚所说的原因是正确的话，那么通过fcitx自己的im module是可以解决这个问题的。其次就是锁死的问题，之所以会锁基本上就是因为有同步调用。且不说不知道为什么xim有那样奇怪的特性，我不能改变xim的行为，但是我可以用我自己的im module的行为来换掉XIM的行为。
这才是更好的解决问题的途径，而不是纠结于显示……
@csslayer
谢谢花这么大精力回复。
Fcitx3.4.2预编译版是跟Iceweasel一起挂掉，Fcitx4.0.1是仅仅Iceweasel挂掉，Fcitx本身还活着。
我可以保证Iceweasel没用多少Swap，如果大量使用Swap，不用动输入法，Iceweasel本身就会在长时间读盘中停滞不动了。
“XIM很坑爹的一点如果一个发给输入法的请求较长一段时间内无法得到回复，输入程序就有可能变成freeze的状态。而且即使杀掉输入法也无法恢复。”，应该就是这个原因了。所以我的主意就是让输入法快点回复，别让XIM等。
我发现如果Iceweasel非正常退出，哪怕关机了，再启动时在Flash里输入过的内容有时还在，应该是每输入一个字时Flash就在写盘了，只是不知道写在哪里。与此同时，每输入一个字，五笔也在写盘，写Wubi_LastAutoPhrase.tmp(这个临时组词功能对我来说没什么用，而且经常捣乱的把一个词的后一个字和另一个词的前一个字重新组成荒谬的词，跟在码表提供的词的后面。可我不知道怎么关掉它)。本来五笔的逐级提示每输入一个字词就要提示近二十个字词(如果提示数定为5的话)，每个字又是动员Pango找字体又是读字体文件又是写字体Cache，又是动员Cairo画AA，读盘就读得不亦乐乎，再加上Flash的自动记录功能和五笔的临时自动组词的保存同时抢着写盘，如果不容电脑反应，瞬间一股脑连续输入三四个四五个词，XIM就该坑爹了。
cat /usr/share/fcitx/data/table/wbx.conf
[CodeTable]
Name=Wubi
IconName=wubi
File=wbx.mb
AdjustOrder=AdjustNo
Priority=1
UsePY=True
PYKey=z
AutoSend=-1
NoneMatchAutoSend=0
UseMatchingKey=True
MatchingKey=z
AutoPhrase=True
AutoPhraseLength=4
AutoPhrasePhrase=True
SaveAutoPhrase=3
ExactMatch=False
PromptTableCode=False
Symbol=zzzz
要关掉临时自动组词和自动保存.config/fcitx/table/Wubi_LastAutoPhrase.tmp的功能，又保留Ctrl+8组词功能，需要改哪个参数？如果改个参数就能解决死锁问题，就太好了，大家都省事了。
至于dbus，是我误会了。我把 Use DBus to display UI (Require KIMPanel)和use dbus混为一谈了。
@litkt
关掉改以下两个。
AutoPhrase=False
AutoPhrasePhrase=False
@csslayer
AutoPhrase=False
AutoPhrasePhrase=False
改任何一个，Ctrl+8的功能都消失。我试着仅把SaveAutoPhrase=3改为=0, 就不再边输入边自动写.config/fcitx/table/Wubi_LastAutoPhrase.tmp了，Wubi_LastAutoPhrase.tmp仅在退出Fcitx或切换至其它输入法时写一次。谢天谢地，死锁问题有望就此解决。如果不再有死锁现象，死锁的原因就应该是Flash和Fcitx的五笔企图同时写硬盘造成的资源冲突，不让Fctix在输入时写盘就能避免这个冲突。
同样思路，再把Priority=1改为=99, 反应变慢(还可以忍受)，但乱序问题大大减轻了。
感谢博主与我这个从不编程的终端用户耐心讨论问题，把我的思路引向了正确的方向。好了，现在不再建议博主在输入条字体上回归X点阵字体的原始社会以提高反应速度，只建议再发布时修改五笔Priority和SaveAutoPhrase的预设值为99和0就可以了，不是为我，是为和我一样在旧机器上用五笔写字的小众。
对于英文补全，我有个一荒唐的想法，用不定长码表轻易解决——每个英文单词及其语法变体的输入码就是它本身，码表就象这样
made made
make make
making making
当输入ma，提示
ma
1de made 2ke make 3king making 4ma mama 5mi mami
让右京兄用Space、左右Shift和数字键补全就行了，如果他不嫌烦的话。
至于德文补全，还可以用兼容码表，比如
München München
Muenchen München
以同时方便有或者没有德文键盘的用户。
如此看来，这个功能的实现，其实不劳博主，想用的人比如右京兄就可以自己写码表(可用现成的词汇表用程序自动实现)自己用，用好了提交码表给博主发布就是了。
乱序是减轻不少，死锁却并未杜绝。期待Im-module早日进入Debian。我的gcc编译环境有问题，自己用源码编译Fcitx总不成功，只能期待Debian代劳了。
@litkt 改了priority有变化一定是你的错觉……因为那个是调整输入法顺序用的……
@csslayer
是错觉。一上午感觉了来出。现在又回到当初的建议了——保留使用原始的PCF点阵字体的接口，给低档机用户自行设定点阵字体的机会，以尽可能减少输入条逐级提示中的字体有关的计算和IO操作。
同时期待替代XIM的IM-Module早日进入Debian。
@litkt 西文补全问题阁下的想法是对的，我没考虑到分析语的变化问题。其实我也不用英文自动补全，当然也不会德文。不过补全功能本身和“一个软件只做一件事”的Unix哲学并不冲突，仍然是为了（如our1944这样的部分人）提供输入方便。
关于pango的依赖问题，博主本人提到由于新手们实在经常遇到字体缺失、难看的问题（相信用过3.x的阁下应该也是领教过的），才最终决定使用pango来自动搜索合适的字体。
关于fcitx“锁死”的问题，其实我曾经遇到过类似情况并且给博主提过，不过浏览器是chrome，且只是浏览器不能输入而并非freeze，并且及时杀掉fcitx的话浏览器也会恢复正常。但是这个问题很少见且不易重现（我不确定是否是因为我的PC不够简朴），log里也没有什么异常提示，所以也一直没有更多东西可供博主参考。
另外我只是个业余的编程初学者，更多的还是以用户的视角去讨论问题。关于我/我的程序是否有对简朴计算机的歧视之嫌，我以为我最多只是在友好和性能之间相对更偏重前者一点，“歧视”则是万万谈不上的。我喜欢python，但绝非不喜欢高效的语言和算法。cairo带来了png皮肤和菜单的支持，也带来了性能损失。但我猜测用cairo画个界面性能损失并不会太大（因为实际上整个皮肤是九宫格围成的，组件很少，最最慢的部分大概也就是中间十字的缩放），简朴机在开一些复杂程序（如firefox）的时候，乱序问题还是会出现的。也许直接禁用掉缩放，然后把字体调到和皮肤合适是更好的办法。前几日我还半懂不懂地看了看fcitx的代码，禁用缩放貌似几句话（改个宏定义？）就可以实现了，比再附带另外一套绘制引擎要实惠、轻便不少（如果不是这样csslayer大神别拍我，我只是提个想法，想法……）。
怎么一回右京浏览器就Freez呢？这次已经僵死三次了。冒火。
字母文字补全如果用码表实现，不影响不用这个功能的用户的性能，所以就不讨论了。
乱序是4.0.1版新出现的，原来的3.4.2版里没有，这也从理论上说明单独从Fcitx方面可以解决这个问题。如果不是3.4.2版导致浏览器死锁更严重的话，我也不会升级到4.0.1版，也就不会来讨论这个问题了。
4.0.1版总体性能上是强于3.4.2版的，但性能上的提升的相当部分好象被照顾新手的措施抵销掉了。为了照顾新手的第一观感，或者为了新手省去阅读说明书然后手动指定字体这样一劳永逸的一次性动作，而增加软件高速工作时的时时工作负担，以至于在低档计算机上工作出现不正常，这是不应该的。这种做法的不同，正是Unix/Linux和Windows的指导思想区别所在。而且我前面说过，输入条上的文字是转瞬即逝的，醒目可读即可，不必美观。对于非常驻界面的鉴赏是无聊的网评员的事，用户没功夫管这些，不管新手老手。
我的建议只是保留多种字体接口以适应不同档次计算机的性能，如果不易实现或者导致笨重，宁可用最原始的接口并自带字体(解决不会指定字体的新手上来就看到缺字和太难看因而不知所措的问题)。我并没有建议由FCITX自己去实现字体绘制，而只是建议自带小些的点阵字体，字体绘制还是交给X，让X用最原始因而最快的字体绘制机制去完成。
АА可选关闭这样减轻消耗的措施在3.4.2版里就已经实现过了，在4.0.1版里反而消失了。
类似AA这样的消耗看似小，但FCITX的逐级提示机制就决定了高速输入时单位时间内字词处理的运算总量极大，每输入一个字词就要瞬时处理提示二十多个字词，以至于运行大型软件如浏览器时再高速输入，低档机就真的吃不消了，所以在每个字上不是必须只为好看的特性还是能省就省的好。我这边能做的就是把输入条提示数减为3,指定内嵌点阵的TTF字体以减少AA计算(如果这样计算量不减反增请高手告知)，我不能做的就只好求助博主在下一版中多少倾向于照顾低档机小众了。
@litkt
建了一个新的项目 https://github.com/csslayer/fcitx-light-ui 。总之就是只能用3.6时候那种无AA，以及xpm图片。软键盘我实在懒得再移植回来了。另外也不会有以前那么多的颜色配置。
反正现在界面成了一个独立的模块之后，随便怎么换都方便。至于最后在你的机器上效果如何我就不知道了。
事实上我倒是发现换成现在以前的XFontSet这个方式的字体渲染之后……如果遇到字符集没有的字就会大卡一下……而且在创建字符集的时候也会大卡……我不认为以前的无AA的实现是一个很好的方案。（其实我从来没真的自己用过无从前AA的fcitx方式，不过看起来问题很大……）我会再换xft试试看。
其实说不定你把cairo配置成点阵字体之后就ok了。或者编译时把pango禁用掉。
@csslayer
把Cairo配成点阵字不是好主意，别的软件还要用矢量字和AA的。我只是建议FCITX的输入条这种偶尔溜上一眼多数时候看都不看的界面可选(这可能只是五笔用户的习惯，所以只建议可选)不用Cairo和Pango，或者可选关闭AA，因为五笔高速输入的情况下输入条的单位时间处理量真的是很大。如果用点阵字体造成缺字大卡，那就还用Cairo好了，只希望留下关闭AA的选项。作为最终用户，编译有困难(就是明明装全了gcc/xorg-dev等一系列组件，./configure还是找不到works的gcc编译器)。
如果指定了一个比较全的字体(覆盖了当前输入法码表中的所有字)，是否开不开Pango对性能影响不大呢(Pango在Fcitx里的作用好象就是在缺字的情况下找替代字体，如果找不到就给一个带Unicode码的方框吧)？如果是的话，就没有必要讨论关不关Pango了。
由于增加和减少输入条提示的数量对性能影响显著，所以我才把注意力放在每个字的渲染计算量上。(逐级提示是FCITX的优点，就是五笔用户遇上生僻字偶尔还是要看一下的，不好建议关闭)。
联想到故障经常只发生五笔上，除了与其他输入法相同的逐级提示的字词选用和渲染处理的计算外，相对于短语和整句输入的输入法，五笔的特点是每输入一二字就要开关一次输入条并重新计算输入条的光标跟随位置，是不是这个影响更大呢？那我试试关闭光标跟随再向博主反馈汇报吧。
这些天麻烦博主了。
@csslayer
XFT是个好主意，期待FCITX简单界面版早日进入Debian。
关闭光标跟随的结果是，还不能杜绝死锁。
今日Debian Wheezy升级了Iceweasel，在里面输入时显示速度更慢了，但好象乱序消失了。再观察两天看看。
@litkt 我已经把新版把切换光标跟随的功能删了，事实上太多人错按到这个了。
不过在另外一个五笔用户的建议下，加入了这样一个功能。因为现在可以支持在客户端窗口中显示当前输入的内容了，可以配置成无候选词不显示输入窗口或者只有一个候选词不显示输入窗口。然后你可以再配合把ExactMatch设置成True，最后就是只有重码才会有输入窗口了。
cairo配置成点阵只是说你把fcitx的字体配置成点阵而已……在配置的font那里写个点阵字体进去就行。
至于说库上面，貌似xft还是会比cairo性能好一点点？
@csslayer
在配置的font那里写个点阵字体，怎么写？类似-misc-fixed-medium-r-normal–14-130-75-75-c-70-iso10646-1这样的格式可以吗？
随着Debian Wheeazy里Iceweasel升级到5.0, 前面所说的问题好象突然都消失了。Fcitx4.0.1版在Iceweasel上的问题就是反应速度有点慢。
我现在暂时退回了3.4.2版，速度好象也不成问题了。再观察一段时间以后再讨论吧。
@litkt 不是
你在命令行执行
fc-list :lang=zh （用fontconfig找有中文的字体），然后把名字输入复制到字体那里。
从里面选个是点阵的字体吧。我这里有unifont和Fixed是点阵。另外还有wqy bitmap song。
@csslayer
这样啊，这样好象是把点阵字体伪装成TTF字体中的内嵌点阵使用 。纯点阵字体是fc-list不出来的。如果这样使用点阵字体，跟直接使用TTF中内嵌的点阵，性能上差别大吗？就是调整字体大小使TTF字体中内嵌的点阵显示出来，也就省了矢量-点阵转换和AA缩放计算。我一直就这么用着来着。如果性能差别大，我就按你建议换点阵。
Iceweasel升级后到5.0后，一切突然顺利了。过一段时间再看吧。
@litkt 老实说我不知道……
哪日你有闲工夫自己测试下好了。
@csslayer
已经不习惯3.4.2的五笔词库，又换回4.0.1，按您的建议打开ExactMatch精确匹配，显示速度问题也基本解决。早我怎么没注意这个选项呢？就象节能减排一样，光纠结于降低单位能耗远远不够，直接减少不必要物资消耗更立杆见影。要是五笔的ExactMatch缺省是True就好了。感谢博主多日帮助。期待fcitx-light-ui。
文泉驿点阵宋体和TTF内嵌点阵的性能比较已经不重要了，我也懒得测了。
perl,perl！添加perl支持。python太慢。
我不喜欢fcitx4xx里面自带的皮肤怎么办。对我而言，一个好的输入法应该是开箱即用的。但是默认的皮肤看起来太让我闹心了。我真的很怀疑贵程序员的审美标准。。。尤其是那个dark theme。好歹咱用fcitx也是从3.4时代用过来的。yuking不说别的，在3.6.3里面改了默认配色方案，应该从fitx里面port来的。非常养眼。4xx自带的皮肤编辑器我看不懂，也没兴趣花时间研究。所以我退回3.6.3了。
@ttk ……classic不行嘛？那个不基本上是3.6时代的样子嘛。
那怎么可能一样。classic跟3.6.2前的默认配置差不多吧，我也没仔细看。都勉强算堪用的程度，说不上很好。
问题不仅在于此，皮肤的引入初看是一大进步，然则实际上问题很多。
第一，制作一款质地优良的皮肤绝非易事，在整体色调协调性上要下很多功夫才是；
第二，缺乏积极的用户反馈机制，没有一个统一的community来管理、上传自制的皮肤；
第三，在程序里提供一个从网络上获取皮肤的接口，与自己从第三方下载零散的资源，用户体验差太多了。
@ttk 另外你怀疑审美标准你也可以来做啊。我好歹也是从3.6.3就参与开发了，3.6.3的颜色我敢保证也就是和classic一个样子。
另外你说的这些这些我们都早有考虑过，那谁来做呢？怎么做呢？都是一个问题啊。你要想来帮忙贡献我可以给帮忙你提供个服务器资源。当然最直接现成的办法就是在opendesktop.org 申请一个分类，然后用KDE的GHNS直接就可以在线下载了。不过反过来说那个网站是英文的，必然还会有人挑着挑那说不友好。
3.6.3 默认menu见截图1: http://xs.to/media/97012
默认输入框见截图2:http://xs.to/media/97016
这个色调跟classic还是有很明显差别的吧？
我不是说皮肤的引入不好，这个东西就跟别人评论KDE一样，画一个华丽的大饼，然而实现呢？如果有兴趣，可以去一个fcitx用户比较多的地方，做一个调查，看看对默认皮肤的满意度。当然，我没有自信到认为大部分人都觉得默认皮肤不行，但是至少我对这个调查结果还是很有兴趣的。
话说回来，至少在我看来，原来改配置文件就可以得到对外观的完全控制，更符合KISS原则。现在用png堆皮肤，自然会更加华丽，但至少我个人觉得用皮肤简单，做皮肤更难了，尤其是做高质量的皮肤。根本的理念分歧是在这里。no offense。反正FOSS么，大家都有源码，有分歧很正常，大不了自己再按自己的idea重新port一个就是了。。
@ttk
这是google code 主页上的截图：
http://lh6.ggpht.com/_yC8eGLRaa_w/TMak1jEBC3I/AAAAAAAAAfQ/e4m7-m66LFU/fcitx-classic.png
除了一些图标颜色差别之外，我觉得差别不大。
当然现在hg里面的那个版本输入条上企鹅去掉了。
说到port我还真port了一个
https://github.com/fcitx/fcitx-light-ui
虽然我着实懒得完全改成原来那样了。
我看到那个fork了，不过我还不是很明白具体patch或者说merge代码的流程。
@ttk fcitx的模块化了，这个以后就是另外的单独的界面模块，可以运行时替代掉现在的，也不会合并什么的。安装之后到时候直接 fcitx -u fcitx-light-ui 就可以了。
至于你说一般开源软件的流程……如果是github这种方便fork的话，那就是自己直接在界面fork一个，然后用pull request要求他人merge你的代码。否则就是抓下代码，通过git/svn/hg diff获得你修改的差异，然后把得到的patch发给对应的邮件列表。
progit这书里面有介绍： http://progit.org/book/zh/ch5-2.html
倒不是那个merge的问题，因为之前我是以为classic UI和light-UI只能二择一。
另外，挂在google code上面的fcitx dbus功能烂掉了。。
现在fcitx越来越复杂了。。。只是感叹一下。。
@ttk 哪有fcitx dbus？……你说那个分支吗？……早就合并掉了，那个分支当然没用了。
dbus指的是跟KIMTOY配合的问题。
@ttk 如果Kimtoy有问题，那说明他的实现不完全和kimpanel相同。（事实上也确实是的）。不过起码我hg里面的跑kimtoy看起来没问题。
fbterm 支持，最希望实现的功能。控制台下缺少中文输入法感觉是linux对中文支持的一个缺陷。