Author Archives: csslayer
FAD 2011
2011.10.15 上午的部分同一个话题重复了太多次，而且商业化的部分其实感觉没有非常实质的内容（中国人还是喜欢赚钱啊:) ）。倒是下午同一天的会不少没法都去听听看。其实老实说一整天我都很困，因为前天兴奋的没睡好…… 中午吃饭人很多…… 下午做Speaker，老实讲一开始对这个话题感觉也有点微妙，因为很难在现场深入到太多代码的细节里面去，结果最后倒是做了不少KDE的演示。另外本来Slide里面有中文的，现场改成了全英文的…… Transifex是个非常好的工具，这边l10n.kdecn.org就是个自己搭建的Transifex，大概单独介绍工具也比较枯燥，所以加入了很多关于翻译的内容。其实Transifex的命令行工具也很有意思（离线翻译其实蛮有用的）。尤其是在和版本库的同步使用上。例如Owncloud的代码库就可以发现Transifex的配置。 jcome的Synfig介绍让我头次知道原来也有个开源的2D动画制作软件，当然最初的感想就是一个类似Flash的（好吧，我啥都不懂），不过已经过了那个什么都想试试的年代了。大概也不会去跑去玩玩。其实说起来开源的很多不错的项目都是由很少的人在支持的，算是存在着用户少于是开发者更少的尴尬局面（由于这些软件的专业性）……对这些项目而言大概我们能做的最直接的只有经济上的支持了。 Texlive的时候非常困（由于其实这部分还算比较了解……）于是就睡了一会。（Fedora的TexLive打包一直值得吐槽到今天……） 另外见到了IBus的开发者一名，他现在有在做libpinyin和ibus-pinyin的开发，由于他是paid的……于是schedule不能像我一样爱在样咋样。另外关于现有拼音的feature，他也有类似的看法，就是虽然ibus-pinyin和fcitx自带的那个拼音都很烂，但是没有另一个能完全替代现有功能的。 之后由于次日要考试，于是就闪了……要是有更多的时间的话还希望晚上能更多讨论一些。
Fcitx 4.1.2
fcitx 4.1.2 1、增加ABI检查。 2、支持状态分组，可以按程序或者全局使用同一个状态。FreeBSD下采用libkvm检测进程名称。 3、支持默认设置为开启或英文状态 4、修复码表的排序和连打问题 5、支持双击安装后缀为.fskin的皮肤 6、增加一个DBus的属性，可以在线修改输入法的启用状态 7、配置文件保存时枚举类型写入可选值的注释。 8、API修改，隐藏一些Struct，为了今后更容易保持ABI的兼容，输入法在注册时可以提供所属语言。区分在fcitx界面显示的预编辑字符串和在程序中显示的预编辑字符串。 9、拼音输入时程序中显示的预输入文本显示中文，以及固定光标位置。码表也固定光标位置以使得输入框不随输入立即移动。 fcitx-sunpinyin 0.3.2 1、支持用CTRL ALT 数字删除曾经输入的候选词。 2、修复双拼方案问题 3、程序中显示的预输入文本显示中文，以及固定光标位置。 fcitx-googlepinyin 0.1.3 1、和fcitx的API修改同步 2、程序中显示的预输入文本显示中文，以及固定光标位置。 fcitx-cloudpinyin 0.1.2 1、增加百度的云输入法的作为一个新的来源 2、fcitx自带的拼音可以记忆云拼音输入过的内容。（sunpinyin由于sunpinyin自己的api原因暂时无法实现） fcitx-ui-light 0.1.2 和主干API同步。 kcm-fcitx 0.2.0 1、支持fcitx 4.1.2增加的DBus接口，用于动态启用和禁用输入法。（演示） 2、增加皮肤管理的界面，支持在线下载kde-look.org 的皮肤。（演示） 3、修复重置操作的bug （没有更新的组件可以recompile后和此版本一起使用）
KCM Fcitx 的皮肤管理器
http://blip.tv/file/get/Csslayer-FcitxSkinManager310.mp4 老实说虽然有段时间自己不用皮肤功能了（用自己重写的kimpanel去了），不过还是把这个功能做出来了。 不久之后的更新4.1.2那批更新之后就能看到了哦。 感谢Ukyoi的Qt皮肤绘制部分的代码。直接拿来用了，不好意思 😀
运行时移除和添加输入法
还是直接贴视频好了。其实是困扰人民群众多年的问题吧…… 通过一个DBus的Property实现的。查询这个属性可以获得当前的输入法列表（包括禁用的和可用的）。设置这个值就可以调整顺序以及启用或者禁用了。 和以前古老的把“优先级设置为0”那个禁用方式不冲突，只不过用那种方式禁用的将不会出现在可用列表里面。
找到那些安静消耗你电池的家伙们
总之神器就是powertop。 首先，不要以为cpu的占用看起来非常低，就没人消耗你的电了，不是这样的。这在我开发fcitx的时候也有注意。比如说，实现一个等待操作，阻塞和轮询的差别不仅仅在性能上。即使每次300毫秒醒来一次看起来对于性能没有影响的情况，在使用电池时也会产生很明显的影响。 这次不幸knotify4中枪了。 在使用gsteamer后端的时候，knotify4不幸排在了powertop的前列。 似乎是这个bug，我换成vlc后端之后就ok了。 http://bugs.kde.org/156215
