Before those NIH guys harm the world.
Thanks @doublechou’s first shot.
http://lists.opensuse.org/opensuse-factory/2012-05/msg00169.html
Before those NIH guys harm the world.
Thanks @doublechou’s first shot.
http://lists.opensuse.org/opensuse-factory/2012-05/msg00169.html
fcitx 4.2.3
1. Lua extension support, same interface with Googlepinyin.
Lua 扩展支持,采用Googlepinyin的接口,支持整合类扩展和命令类扩展,暂时不支持转换器。(需要编译时开启)
2. super can be used in hotkey again
Super(win) 可以再次被用于快捷键中
3. fixes Trad-Simp native engine in chttrans.
修复原生的繁转简支持。
4. Update fcitx-pinyin algorithm
更新fcitx-pinyin的拼音切分
5. txt2mb and mb2txt support new English format
txt2mb和mb2txt支持的英文格式的码表
6. Fix a crash when enable share status.
修复在设置为共享状态时可能导致的崩溃
7. Add surrounding text support.
增加获得周围文本的支持。
8. Commit input when unfocus.
失去焦点时提交输入
9. Classic UI improvement, including trayicon, menu.
经典界面改进。托盘图标居中并且不会被放大。
fcitx-fbterm 0.1.4
kill the fcitx and dbus-daemon launched by the script
在退出时杀死由脚本启动的fcitx和dbus-daemon。
fcitx-sunpinyin 0.3.6
option for memory strength, enable fuzzy segement by default
增加记忆强度选项。
fcitx-keyboard 0.1.3
1. add existing keyboard layout on first start up
在首次启动时加入当前已经配置的键盘布局
2. try to set fcitx “first input method as inactive state” when install
将fcitx默认设置为第一个输入法作为非激活状态。
3. restore origin keyboard layout on exit.
在退出时恢复键盘布局。
fcitx-chewing 0.1.2
1. fix space key
修复空格键的处理
2. fix issue 553
修复 issue 553
kcm-fcitx 0.3.3
1. add super support.
增加super(win)键的设置支持
2. workaround a potential freeze bug
绕过一个潜在导致界面冻结的错误。
fcitx-configtool 0.4.3
lower gtk2 version library request compatible to RHEL/CentOS 6.
降低gtk2版的库要求支持,可以满足在RHEL/CentOS 6上的编译依赖
fcitx-m17n 0.1.2
add surrounding text support.
增加获得周围文本的支持。
fcitx-hangul 0.1.1
add surrounding text support.
增加获得周围文本的支持。
fcitx-table-extra 0.3.0
add more table from ibus-table-chinese.
增加更多在ibus-table-chinese中的码表
fcitx-table-other 0.1.0
Fork of ibus-table-others.
ibus-table-others的fork。
fcitx-unikey 0.1.0
unikey support for fcitx
fcitx的unikey支持(越南语)
kimpanel-for-gnome-shell
Menu support, and move it top of other window.
插件已经上传到 https://extensions.gnome.org/extension/261/kimpanel/ ,目前的最新版相比之前增加了菜单支持,并且显示时不会再被某些窗口遮挡。
在奇葩的Linux输入法世界里面呢,经常上演着这样的事情。
被程序不幸没有做正确的行为。
但是有办法可以walkaround,但这个walkaround又可能导致另一个没有做正确事情的程序出问题。
于是 ╮(╯_╰)╭ 。
来讲两个故事。
首先是WPS和Opera的故事。
XIM 有两种 Style,On The Spot 和 Over The Spot,前者不可以光标跟随,后者可以(当然这只是Qt自己的实现的问题)。我在考虑了很多人用 Fcitx 的以前都手动设置过环境变量强制用了xim,于是虽然 Fcitx 可以支持 On The Spot,不过默认没有开启(程序选择Style的时候优先选择 On The Spot,其次是Over The Spot)。
于是假设来了两个程序,Opera和WPS,Opera不幸只能在On The Spot下光标跟随,WPS由于多数发行版的Qt是4.8的,无法使用系统的IM Module,于是只能fallback到xim。那么Fcitx的这个默认设置就只能导致Opera不能光标跟随,WPS可以 ╮(╯_╰)╭
其次是Sublime和Thunar的故事。
有个人先给我汇报了一个Bug:“当fcitx启动时,在thunar里不能使用字母直接跳到相关
研究了一下发现这应该是gtk所有list view类的搜索共同的问题……于是我很快发现应该判断当前是否获得了焦点,以决定让IM Module是否处理输入法的按键。
然后于是我 Push 了代码。
http://code.google.com/p/fcitx/source/detail?r=11784e514dd3d1654481bdf12bd1e368832229c4
后来 Sublime 这破玩意出来了(闭源的Gtk程序,感觉这辈子没见过几个……),由于刚刚说过的那个Bug,反而导致Fcitx可以在里面输入,但是修复之后就变得不可以了。(老实讲我后来gdb attach进去手动改掉某个bool变量测试发现果然就变得可以输入了,以证明我发现的原因是正确的……)
再回来抱怨两句Sublime,这玩意闭源就不说了,唯一能够获得支持的只有个论坛,关键这论坛还他妈要发信给某个邮箱才能获得邀请码注册,您防Spam能换个友好点的方式吗?老子好不容易注册了然后发帖了还没人鸟我,我擦!再加上这破玩意是闭源的,老子连替他擦屁股的方法都没有。
===========================================
只要微笑就可以了……
===========================================
P.S. 这故事要讲下去还有很多后续
比如LibreOffice和Firefox的故事等等等等。
只想在最后重复一下我的原则。
1、当能同时Walkaround两者时,我会选择Walkaround两者。例如LibreOffice里面的历史悠久的掉键,在换成IM Module之后可以得到Fix的话,那我就不会使用会让firefox产生一个小问题的Walkaround。
2、当不能同时Walkaround两者时,我会选择我认为比较重要的那方Walkaround。例如前文说的那两个。
3、我基本不会使用针对某个程序特别的hack,除非我认为这个程序非常重要,例如在代码里面判断当前程序是不是sublime我是不会做的。
=-=-=-=-=
Powered by Blogilo
仅代表个人观点。
这些话其实我很早就想说了。
Open Source 本来应当是自由的,或者被许多人认为是自由的,实际上完全不是这么一回事。
1、关于开源和开放
比如这个项目 Mozc,很明显他是个开源项目,但是并不是开放的,看看他的提交人就知道了:http://code.google.com/p/mozc/people/list
清一色的Google 雇员。而且在svn的提交历史内是几乎看不到它是如何开发的 。(写过代码的人都知道,一般都不会有如此大的commit)。
不开放体现在:
1)不公开的代码历史
2)不接受其他人加入
当然这实际上阻碍不了我们去用它,uim和fcitx都干了类似的事情。
2、选择权
用了开源的东西你就拥有了选择权吗?不一定。选择权其实还基本处于开发者的手里。举一些不恰当的例子。
有些人喜欢用平铺式窗口管理器,那么如果某一天发行版被切换到了Wayland,那么可以想见的是曾经的那些五花八门的窗口管理器都将不能使用。好也许你的回答是我可以不换到Wayland,继续用我的XServer。但几乎可以肯定的一点就是,选择权在多数人手里,对于一个复杂的系统来说,单枪匹马的维护几乎是不可能的。
谁也不能保证在将来的某一天,某个软件就失去了支持。事实上你使用开源软件的道路是不是总是被一股看不见的潮流在推着走呢?
在某些情况下,也许还可以作出辩护,嗯,这个东西更好,所以别人取代了他。更多时候问题是两难的,有两个甚至更多的项目,因为理念的不同而没有合并成一个,但是也无法回答究竟谁是更好的项目。
3、选择权在谁手里
很多时候还是在那些公司手里。事实上我还是更加喜欢那些看起来就直接是想要赚钱的公司,而不是那些号称要拯救世界的公司。
因为无论他们是怎么说的,目的都是一样的。
这也算是我选择KDE的原因之一。