捡起来唠叨一次：），发现看我blog的人（都是google来的啦），大部分关注我那个ati显卡的，可惜……那个没有啥教程性的内容……其次就是一个kimpanel的faq啦，就是希望用kimpanel的人能够少走些弯路：）
进入正题
我用linux也蛮久了，听歌始终是一个重要需求，首先和往常一样，先列出吐嘈对象，然后再吐嘈。
用过的：MPD，quodlibet，Amarok，Juk，rythmbox，songbird，xmms，mplayer
没用过的，就不提了：banshee，deadbeef，lxmusic
参考了gtk qt的代码，终于实现了透明：），这是一小步也是一大步
gtk你就是渣渣……真难懂，其实也不是你的错，谁让你的渲染又利用了cairo呢，摊手（茶）
核心的参考资料如下：
qt的实现：
http://qt4-x11.sourcearchive.com/documentation/4.5.1-2/qsystemtrayicon__x11_8cpp-source.html
官方文档：
http://standards.freedesktop.org/systemtray-spec/systemtray-spec-latest.html
gtk的实现：
http://git.gnome.org/browse/gtk+/tree/gtk/gtktrayicon-x11.c
kde的人写的资料：
http://ktown.kde.org/~fredrik/composite_howto.html
具体参考TrayWindow.c吧……累了不说了
……在没注意到的时候……
于是开gdb启动之。结果偏偏不出问题……也许是切换了输入法之后才能出现，回去再试试
唉……少见的情况不好调试……
留下个qt的地址好好研究
http://qt4-x11.sourcearchive.com/documentation/4.5.1-2/qsystemtrayicon__x11_8cpp-source.html
主要问题是到了cairo那里我就没辙了……整整一个库的调用我实在研究不下去，不如看看qt？
这次恐怕能说的上是可以告一段落的情况了：），dbus当中恢复了几个没有注意的问题。
我现在可能将目标主要转向关注内存泄漏上面…
已经将fcitx打包安装在自己的电脑上，目前就是测试了，修补了几个以前没有注意的地方，仿佛性能也流畅了起来，大概转换编码还是有些辛苦的吧……？
内存占用上其实我是支持in-memory hold，性能确实不错
utf8带来的新特性：大字符集输入，以后可能可以加入［超］生僻字了
fcitx现在支持的字符输入应该也不少了，刚才特意测试了一下zh_TW.BIG5的locale，也很顺利，只不过要先把繁体打开，估计zh_TW.UTF-8输入简体也没有问题。
