这次主要希望测试的有新完成的gtk im module和qt im module,我自己这边只有Qt和gtk2能覆盖到,如果有gtk3/gnome3的用户也希望能够帮忙测试。
由于我是Chakra用户,目前就只给Arch和Chakra的用户准备了PKGBUILD。这个pkgbuild当中加入了gtk2,gtk3,qt的编译依赖(实际使用中可以拆包或者不进行编译),可以根据自己的需要去除一些依赖。(当然你完全去掉这三个也没关系,还有XIM可以用,不过这就不是本次主要测试的目的了。)
这次主要希望测试的有新完成的gtk im module和qt im module,我自己这边只有Qt和gtk2能覆盖到,如果有gtk3/gnome3的用户也希望能够帮忙测试。
由于我是Chakra用户,目前就只给Arch和Chakra的用户准备了PKGBUILD。这个pkgbuild当中加入了gtk2,gtk3,qt的编译依赖(实际使用中可以拆包或者不进行编译),可以根据自己的需要去除一些依赖。(当然你完全去掉这三个也没关系,还有XIM可以用,不过这就不是本次主要测试的目的了。)
这次写它的理由就更有意思了……
因为我单纯的觉得让用户发现QT_IM_MODULE和GTK_IM_MODULE竟然不一样会很蛋疼,于是就趁热打铁一口气写了……同时也让两大UI Toolkit的IM MODULE都齐全了……
还在调试……另外感想就是果然c++比c方便写继承什么的……
这个环境变量头一次可以设置成这个值,从前这么设置都是错的是错的啦!
我平时用的gtk程序太少……只能用firefox和thunderbird来测试了。
具体实现当然参考了各种已有输入法的im module,从ibus搬了不少代码过来呢……
刚刚愉快地在firefox的flash中输入了一句话,在不用hack的前提下。
不过firefox的光标跟随依然不够完美,不过比以前跟的紧就是了…… ( ̄ˇ ̄)
人其实就是为了自己活着的。做出选择果然都是为了“无愧我心”,有什么可愧的,站到了自己心中的制高点上而已。
冠冕堂皇的话都是放屁,选择这个或者选择那个,万语千言到最后其实都化成一句话,“我很牛逼,我觉得你是傻逼”。然后对方要么世界观崩坏改进他的不傻逼的标准,要么心里也觉得你是傻逼。
人类进步的原始动力。每每这么想就释然了。
首先诸君没必要给Fcitx加上各种定义,定义是人定的。最重要的就是开发者定的。然后不幸,现在这个人是我。
轻量?简洁?快速?这大概是多数人对于fcitx的看法。
我心中的理想的fcitx是什么样的?
可用性(Usability),原生(Native),KISS。
第一条,在这方面做的努力可能注意不到,在3.6时代困扰不少人的方块字问题,后来通过Fontconfig和Pango(如果禁用Pango就是Fontconfig找字体了)得到了相对比较好的解决。
第二条,这单纯是个人喜好,似乎也是很多linux用户的喜好。界面要原生。Fcitx的界面原生吗?没有使用GTK/Qt,谈不上原生,但是这个皮肤引擎给了Fcitx原生的能力,比如我就曾经写过一个小程序,使用KDE的Plasma主题生成Fcitx的皮肤。
即使对于GNOME来说,我其实也没有必要去写什么利用GNOME-Shell做的界面,不过他那个bug如果不给我解决掉(不是那个xim的,是关于界面显示的,其实是影响所有程序的一个bug),那还是只能悲剧。
第三条,Fcitx的架构其实一直非常简单,一直也没有引入什么更多的外部依赖(除非有必要),现在Fcitx需要发展的话,其实将不得不使用更多依赖,不过不用担心,这些不仅可以在编译时确定,同时也可以在安装时,运行时确定。
为什么我一直执着于不引入高级库的抽象?除了为了满足一些人的洁癖之外,更重要的原因就是保持简单。对于内部的事件处理,虽然当然也可以用比如libevent,或者gio,或者别的什么,但是它相对也不会带来什么用户可见的好处。(最影响Fcitx速度的部分是输入法引擎,用sysprof测定过),增加我的各种学习成本……
另外也就是留下各种余地,如果有一天Fcitx要做更大的跨平台动作,那些某个平台上没有的库希望也不会成为阻碍。
$ ldd /usr/bin/fcitx linux-vdso.so.1 => (0x00007fff4e5ff000) libfcitx-core.so.0.1 => /usr/lib/libfcitx-core.so.0.1 (0x00007f8677546000) libfcitx-config.so.4.1 => /usr/lib/libfcitx-config.so.4.1 (0x00007f867733b000) libfcitx-utils.so.0.1 => /usr/lib/libfcitx-utils.so.0.1 (0x00007f86770fa000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f8676edd000) libc.so.6 => /lib/libc.so.6 (0x00007f8676b7c000) libdl.so.2 => /lib/libdl.so.2 (0x00007f8676978000) /lib/ld-linux-x86-64.so.2 (0x00007f8677754000)
其实Fcitx变得更轻了而不是更重了。
顺便说点别的(虽然我想说点Neta…比如和Fcitx签订契约成为魔法少女吧!)
欢迎有兴趣参与Fcitx开发的人和fcitx-dev@googlegroups.com联系(我很讨厌可以将联系更加公开的时候联系我个人,所以不要给我发信)。至少现在还是有很多事情可以做的,不过你指望有人付钱那是没戏的……
比如说:
fcitx-anthy(有个挖了个坑连水都没填的家伙说要做这个,所以不必介意他)
fcitx-libpinyin(一个新pinyin库,似乎有各种做拼音的人参与)
kimpanel的GNOME-Shell版本(这个其实和fcitx没直接联系,不过有了这个fcitx在GNOME-Shell下的显示问题就可以解决了)
fcitx-{…},你还能想到的其他功能。比如m17n…或者MAC OS移植等等。