今天调fcitx和kimpanel，以前杯具的sigpipe再度出现，幸好不使用dbus时不会出现这个问题，要不我还不被骂死……
上网查了查dbus的sigpipe，信息不多，感觉一头雾水无从选择……相关的一个信息就是dbus的多线程问题，需要用dbus_threads_init_default，这个问题在当年决定用另外的线程来接收dbus信息时就用上了，所以导致我更加百思不得其解……
幸好这个问题不甚多见，我能reproduce的情况就是，打开拼音，按left ctrl进英文模式，按shift+space切换全半角，然后就sigpipe。甚是杯具。我猜很多人也不这么用，甚至全角都完全不用，所以有幸躲过了。
回到这个问题上来，今天不断的测试之后还是没有解决，倒是有的时候segfault了。赶快看一看，发现问题总是出在property2string这个函数上面，很奇怪，于是祭出valgrind大神救我。
valgrind大神真是好，当年fcitx的dbus功能内存泄露大大滴……用了这个，真是腰不酸了，背不疼了，走路也有劲了，顺道还查出了个fcitx原来隐藏的内存泄露问题。
单纯记录经历就没啥意思了，也说说怎么用上它的，基本上这个命令总是这么敲就好了：
valgrind –trace-children=yes –leak-check=full –log-file=filename commands args
其中第一个参数是记录子进程，第二个是显示完整的内存泄露信息，第三个是制定记录输出的文件，默认是重定向到stderr的。
于是乎，果然让我发现了一个问题，是新写的函数updatePropertyByConnectID有个问题，logo_prop这个变量记录了kimpanel第一个图标的信息，这里我在赋值之后将它free掉了……也许就是这个原因导致的，不过再我改过来之前就被亲爱的打发走了……
回去之后看看是否能解决这个问题。
余下的是杂谈：
话说回来，我还是需要吐吐嘈，dbus实际上大家都在用dbus和glib的绑定（或者qt），这也无可厚非，但是我实在不想为fcitx加入新的依赖，dbus毕竟还是人人都安装的嘛。（什么，你不装dbus，主流桌面你还想用吗，你真的用linux做桌面吗）所以一直只用了dbus的核心部分，结果就没有办法做一个好的事件处理，这让人很苦恼。另外由于开了多线程，幸好有个dbus有个加锁的功能所以才能解决。fcitx确实很轻量级，带来的问题就是可扩展性上的缺失，这也算是一个feature吧……不用kimpanel的人大可以放心不用重新编译，在配置文件里面写上使用dbus接口=0就好，而且默认是不用的，不会带来啥性能和崩溃问题（基本确定，我check过屏蔽的还是很好的）。
用dbus底层接口带来的问题就是得自己搞个轮询……试了试sleep起码没有带来啥性能问题，就暂且放过。
fcitx的界面逻辑和核心逻辑混杂在一起，所以带来了很多问题……但是拆开来难得要做第二个ibus不成吗？……而且恐怕工程量巨大，也没有啥精力去搞这个了……
其实说起来我还给fcitx搞过整体的utf8化哦……当时倒是有初步结果，只不过最后无疾而终了……
说起来我为什么一直执着于fcitx，很多人也执着于fcitx呢？其实我执着的原因还蛮简单的，就是兼容性啊，纯底层x写的输入法，没有gtk，qt的依赖，真是很好的输入法。大多数人可能看重的是轻量吧。
fcitx的拼音输入其实还不错，只不过默认的词库小了点，具体的处理也是hand made的。有时候总会觉得有点遗憾，用了附加词库当然好了很多，不过貌似是最近匹配的算法？有时候输入有点小问题。
如果有人port一个新输入法算法过来可能会好很多。其实fcitx有很多人性化的地方，删除用户词库，record，等等都很方便。
不知道yuking对于小企鹅输入法的将来怎么看，活跃着的开发者貌似只有yuking？……
不知道联系一下学校的协会怎么样
