1、4.x 之后不要问怎么改配置文件。fcitx-configtool 和 kcm-fcitx 是你的朋友。我虽然熟知如何手动修改配置，但别指望我会告诉你们。
2、不要争论关于依赖的问题。
你洁癖你自己靠边站。况且依赖也不多嘛。
3、请用 IM Module，在Ubuntu，Debian上这个包叫做 fcitx-frontend-{gtk2,gtk3,qt4}，我已经要求打包者默认安装fcitx的时候安装这些（目前还只默认装 gtk2 gtk3）。在 Fedora，OpenSUSE，Chakra，Archlinux上这个包叫做 fcitx-{gtk2,gtk3,qt4}
4、我在 Issue 的默认模板那里也写了
http://fcitx.github.com/handbook/chapter-config-env.html
http://fcitx.github.com/handbook/faq.html
这两份文档是你不能正常使用 Fcitx 的时候应该阅读的。可以自我检查配置是否正确。（附带一提，Ubuntu 11.10 里面 im-config 带的 fcitx的配置只能把fcitx配置成使用 xim，debian sid 里面的im-config已经修改了……如果你要用 4.1 + 的版本的话，so，要么你手动改 /usr/share/im-config/data/80_fcitx.im 里面把xim改成 fcitx，然后im-config，要么用第一个链接的后半部分 (有关 ~/.xprofile) 自行配置）
Fcitx 在能够成为系统默认输入法之前，这些工作/麻烦是无法避免的。
5、虽然被很多人无视，Issue List 不是提问的地方。fcitx [at] googlegroups.com 才是。googlecode首页上有通过发送邮件的加入的方式。（免得遭遇你懂得的麻烦）
6、这是一个新问题，主要是 googlecode改了代码checkout链接了（github部分不受影响），想抓代码的人请用以下地址。（googlecode页面上是 google.com + https ，如果你不懂为啥这地址有问题就别继续问了）
http[s]://fcitx.googlecode.com/git/
http[s]://子repo名.fcitx.googlecode.com/git/
7、不光针对 fcitx 的，任何时候遇见问题，不要着急确定原因。搞好逻辑关系。可以先提问（提问方式参见上面），但不要先汇报Bug，4.1.2 发布以来 73 个汇报中，超过 60% 的 Issue List里面的，要么不是Bug，要么是Fcitx之外的原因导致的。
P. S.
我写这篇的原因主要是希望我以后可以直接用这个回答问题…… 上面 handbook 里面的两个链接已经是几乎是我每次出手必引用的了……这些不太合适放到 faq 里面的，就放这里好了。
抢个沙发吧。很久没坐过了。
用 #讽刺腾讯 来回复。:)
唔，高玩们看吧，我只需要ｌａｏｋ ｊｉｕｍｉｎｇ.
建议把“你洁癖你自己靠边占”这句话改成“有必要的话可以自己编译去掉”……这口气太激烈了。
在OBS上把fcitx打成自己喜欢的包还是很爽的……
咦？怎么打“yongbul”出来两个“用不了”？貌似一个是“yongbuliao”，一个是“yongbule”……
“你洁癖你自己靠边占”，这句有错别字。
既然没洁癖，那就把kcm-fcitx集成在fcitx-qt4包里吧，怎样？
fcitx classic遵守的是X设计哲学，简洁、不干预用户做什么。
现在呢？追求的是out-of-box，开箱即用对吧，OK，伟大的梦想！当然你的test-case里面的fcitx总是bug-free的，别的非gnome/KDE用户出了问题，你一句“不应该用独立的WM作为你的桌面”就把问题推的干干净净。哟，fork个open source project还玩出优越感了啊！
你以为用户都是小白么？用户就该低三下四的接受你的安排么？
反正我觉得fcitx 现在已经跟以前的格格不入了。既然fork了fcitx的代码，又不按照原来的路子走，干脆就叫别的名字吧。你对fcitx没有感情，我还是有感情的。
@ttk 既然没改名字就不是fork，不是fork就可以按照自己设计走，这就是自由。而且你为啥要代表用户呢？谁干预用户了选择其他输入法了？谁低三下四了？我觉得fcitx很好。
@ttk @CSSlayer仁兄口气激烈了点，但并非没有道理。对于Fcitx未来之路的大讨论貌似已经有过很多次了，但是众口难调的道理也是很容易明白的。CSSlayer仁兄在维护Fcitx（或者您叫它别的什么），我们在这里讨论，都是源于我们对Fcitx有感情，或者至少有好感，愿意让它变得更好，指责一个开发者对所开发的东西没有感情，实在是让人寒心啊。
当然究竟何种发展方向是对的，恐怕作为用户层面的我们没法说谁对谁错。我在这里只是指出如今Fcitx这种改变的正面意义，仅供参考：
我查了查，X Window似乎并没有“不干预用户做什么”这条原则（当然它也确实没怎么干预用户），最贴边的一条貌似是“我们提供的是机制而不是策略”，也就是说具体怎么实现要靠下游的开发者去解决。然而输入法是个面向用户的程序，总不能写个通信接口，然后让用户去写个界面出来。事实上现在Fcitx支持使用其他输入法接口，支持自定义MainBar按钮这些，也可以看作是一种“提供机制”。
现在的Fcitx仍然可以修改配置文件，方法可以说是被刻意隐藏起来了。但堂堂一个GUI程序，却需要用文本编辑器去改它的配置文件才能实现配置的改变，这正常吗？（我似乎只见过Gnome3把一些本来完全可以提供配置界面的特性隐藏起来，逼迫用户们去改配置文件）现在的方法是用配置程序，配置程序已经涵盖了几乎所有配置文件里可调的内容（至少kcm-fcitx是的，configtool我多年不用了所以不清楚），应该没有再去改配置文件的必要了。如果您觉得多分一个包搞得很混乱的话，我觉得可以建议CSSlayer借鉴@Enih仁兄说的方法，把configtool和kcm-fcitx集成进fcitx-gtk和fcitx-qt里面去。如果您真的想通过配置文件解决问题，我给您支个招——去成为Fcitx开发者。我以亲身经历告诉您，如果您成了Fcitx开发者，CSSlayer会把所有的东西都毫无保留的告诉您的……
关于WM的事情……其实选择了用独立的WM，就选择了自己解决许多必要的问题，比如登陆的时候要进行好多配置，比如窗口、字体之类的也要经过一系列配置。并不是说我们用现成DE的人就有什么优越感，而是现阶段Fcitx缺少其它WM的测试，更缺少使用其它WM的开发人才和配置经验。如果您愿意帮助提高Fcitx在其它WM上的体验，我想CSSlayer会很乐意的。
顺带一提，Fcitx3.x在别的WM下真的没问题吗？我记得在没字体的情况下别说是其他DE/WM，就是在根红苗正的Gnome2下都有问题。
另外说到fork的概念，只要是原来的开发者同意了，即使变动再大，也不能叫fork；而因为不同意这一决议的人另起炉灶才叫fork。好比尽管KDE3升级到KDE4几乎没什么兼容的东西了，不过那不叫fork，反倒是KDE3的支持者正在维护的Trinity才叫fork……
最后……用户当然不必低三下四。开源的精神就在这里，当用户对发展现状不满的时候，协商、成为开发者、fork还是离开这一软件都是自由的。
我并不反对GUI配置程序，作为用户，我不能容忍的是“我虽然熟知如何手动修改配置，但别指望我会告诉你们。”怎么配置fcitx是我的自由，怎么开发fcitx是开发者的自由。如果开发者认为他的想法必然优越于用户的想法，褫夺用户选择的权利，这也许是合理的，但同时我保留发表意见的权利。
关于配置：
fcitx既然是X程序，那么也就是依赖于X11，而不是gtk或者QT。这样的话，为了完成fcitx的配置，那么使用直接编辑配置或者使用GUI进行配置。两者之间并非毫无差异。使用配置文件的话，GTK或者QT仅仅是可选依赖，可有可无。
现在的分歧在于X或者相近的unix设计哲学思想在于，低耦合度，fcitx和fcitx-config各自完成其核心功能，互不干扰。GUI设计哲学在于隐藏尽量多的细节，提供尽可能大的方便性和集成度。在这里我并不比较二者的优劣，只是指出为什么我说fcitx-classic与现在版本的设计思想不同。
关于开发者：
现在fcitx开发有其固定用户群，相信大部分人并不关心细节的改变，很多人也提交了很多issue，至于有没有兴趣去fix，开发者自有其考量。
但是csslayer同学屡次以挑衅的态度评价他人价值观，对不起，我觉得如果你做不到对与你不同价值观的尊重的话，那没有收到别人善意和尊重也是相当正常的。
这位老兄好像没有在Linux下发帖？而且自己好像有点逻辑混乱了。CSSLayer没妨碍你自己修改配置文件啊，他只是提供了另一种配置方式而已。配置文件的内容本来就是自明其义的，想改就改去呗。
嗯，不错
“但堂堂一个GUI程序，却需要用文本编辑器去改它的配置文件才能实现配置的改变，这正常吗？”
这完全正常，而且是在易用性和性能间找平衡的绝佳手段。Xorg下著名的Fontconfig就是这么干的，Xorg本身也这么干(xorg.conf)。
配置这种事一劳永逸，没有必要在追求这个的GUI的上浪费开发者的精力。最终用户也不必完全掌握配置文件的修改规则，这个事情应该由下游的软件组织者去完成各种适应性的配置方案，最终用记只要掌握几点自己个性化屐所需要的一点知识就够了。
更重要的是，唯GUI主义者要求用GUI的方式修改GUI软件的配置，如果预设初始配置不得当，GUI软件本身根本起不来，如果再没有编辑器修改配置的手段，那可就──知道为什么Windows用户动不动就要重装系统吗？这就是唯GUI主义的愚蠢之处。
话说回来，Fcitx作为IME，作用无非就是文字输入，本质上就没有界面，更谈不上GUI。汉字IME用GUI有其不得已之处。其他字母文字的xkbd从键盘布局到配置文件不全是文本吗？哪个用GUI了？不就得在/etc/default/keyboard里设置吗？甚至当初这个设置从/etc/X11/xorg.conf里的键盘设置小节移到/etc/default/keyboard里还造成很多最终用户的一度困惑呢，这又怎么样？谁抱怨过字母键盘设置没有GUI的设置程序了吗？
@ttk
fcitx和fcitx-config各自完成其核心功能
其实Fcitx就是这样做的。我有装任何fcitx-config的GUI程序，当点击Config菜单时自动调用X预设编辑器把配置文件文本给打开了。这其实很好。
你的思路和博主思路并不矛盾。如果你用Debian的话，你会发现你所不喜欢而博主做了的东西其实并未集成，被Debian的组织者拆成了很多单独的小包，你如果不装这些gui配置程序小包，FCITX就是你所希望的样子，装全了，就是右京样一所希望的样子──高度集成──其实只是看起来是这样。
博主与其他Linux软件作者相反之处在于，其他Linux软件作者往往会强硬的拒绝在配置的易用性的编程上浪费精力，宁肯在配置文本文件的提示的易读性上略下些工夫。而博主则宁可多花精力去写GUI配置程序，而不愿把符合各种不同需要的配置文本在网上传来传去。
@litkt
更正，我没有装任何GUI配置程序，少了个“没”字。
@litkt 小吐槽：xorg.conf这个例子比较不合适……容易出现先有鸡还是先有蛋的问题。
@csslayer
合适，其它整合配置的GUI软件也同样有先有鸡还是先有蛋的问题。我在上面说的就是这个。
弱弱的问一句，如果不设XIM，不设LOCALE_CTYPE为zh_CN，QT_Module=fcitx能运行吗？是否还与Compose冲突？
只要设LOCALE_CTYPE=zh_CN，死键就不能用。如果是德文的äöü，突厥文的çğıöüş，因为字母少，还可以用AltGr+cgious凑和，但汉语拼音的带符字母太多了，一共24个，不用死键不行。什么时候能把这矛盾解决了才好。
@litkt 我说的先有鸡还是先有蛋的问题主要是，万一你把xorg.conf搞错，可能连X都进不了了……哪来图形化配置程序。
能用死键啊。不过需要gtk和qt的程序用im module即可，至于说用xim的程序，目前没办法，xim和死键不能同时用。
@csslayer
其它GUI程序如果把设置集成进主程序的话，也有这个问题。
您是说IM_MODULE可以在任意LOCAL_CTYPE下运行fcitx?还是必须用zh_CN，只是不设XMODIFIERS=“@im=fcitx”？
@litkt
和locale没关系
http://fcitx.github.com/handbook/chapter-config-env.html
XMODIFIERS 只影响使用 xim 的程序
GTK_IM_MODULE 只影响 gtk 程序
QT_IM_MODULE 只影响 qt 程序
XMODIFIERS 能够作用于 gtk / qt 程序当且仅当 gtk / qt 程序使用 xim 的时候。
locale 的影响可以通过这三个环境变量覆盖，这篇里面讲了。不管你的locale 是什么，有以上三个环境变量的话都可以用fcitx（除了一些奇葩程序，我了解到的只有emacs，emacs似乎不是cjk的locale一定不会用im module，或者使用 C 作为 locale 但想用 XIM）
https://www.csslayer.tk/wordpress/fcitx-dev/input-method-env-story/
@csslayer
我试了一下，对于XMODIFIERS必须是在LC_CTYPE=zh_CN.X环境中才起作用，IM_MODULE=fcitx在mn_MN.UTF-8(蒙古国蒙古文)下可以，在ug_CN.UTF-8(中国维吾尔文)环境中就不起作用，而且在tr_TR.ISO-8859-9(土耳其突厥文)环境下也不行(这很正常，ISO-8859-n根本就没有汉字的位置)。
不要争论关于依赖的问题。
还是争论一下吧。建设打包者把那个Libopencc1由依赖(dep)改成推荐(reg)。我不愿意因一个繁简转换浪费10M空间。
如果要打简出繁，把vk.conf整理一下，足够了。
@litkt
XServer 似乎不支持ug_CN 的locale（你可以运行一个xterm试试，我这里提示 Warning: locale not supported by Xlib, locale set to C），以至于 Xutf8TextListToTextProperty 的函数失败然后fcitx挂掉了。不过似乎可以walkaround（fcitx不crash，但也只能让gtk/qt程序输入，xim程序不行）。另外你说的没错，如果编码没有要输入的文本，那就不可能输入对应文字，比如zh_TW.BIG-5 的话就无法输入简体而只能输入繁体。
依赖的话opencc是编译时检测，如果你使用简繁转换的话，编译时决定要或者不要。不过fcitx已经模块化了，如果不用简繁转换的话，可以不安装负责简繁转换的模块。debian有没有把简繁转换的模块单独分包我就不知道了。这些问题请联系debian打包者
csslayer兄
这个有问题 啊
fcitx (debian 7)
打字掉字母啊