Tag Archives: qt
输入法环境变量的故事
有时候我想想，我是不是应该写一些比较普及的文档（你懂得，我特意纠结了一下措辞）。 那么这次先来介绍一下关于输入法的环境变量配置问题： 在远古时代，世界一片混沌，那时世界上还没有 X 窗口下的输入法支持。 神说，要有输入法，于是就有了 XIM 协议。 这个时代（当然还有个几个XIM协议的版本更新），需要设置的环境变量有 XMODIFIERS=”@im=imname” 比较现代的程序的话，是不用纠结imname这个值的，输入法自己会自己也检测一把这个值，然后启动xim的时候也把自己变成这个值。印象中一定要这个环境变量的程序有xterm。 然后XIM有诸多缺点，至少在输入法程序关闭（不一定是死掉）的时候，可能让程序freeze，或者崩溃。 于是神看到XIM是坏的，授意GTK和QT自己做自己的IM Module。 从此天下大乱。 先来看 Gtk 这边，假设没有环境变量，Gtk是读取一些配置文件里面记录的im module的。每个im module都有指定语言，也就是按环境的语言设置匹配。这里来第一个常见问题：英语环境为什么默认不能用输入法而要纠结 LC_CTYPE=”zh_CN.UTF-8″。就是为了让 Gtk 的匹配能够匹配中文的IM Module。当然我个人是反对这种配置的，因为其实只要 GTK_IM_MODULE 足以。世界上据我所知唯一一个奇葩程序一定要这么设置那就是emacs。（因为作为gtk界面的emacs其实是用XIM协议……鬼知道里面hardcode了啥） 第二个常见问题，为什么卸载了ibus就可以用 fcitx，那是因为系统中同时有两个zh的im module（其实是三个，还包括了xim），你不设置环境变量的话，那就会让gtk自己选择了，这个顺序似乎也不确定，如果选到ibus但你用fcitx，或者选到fcitx你用ibus，都会导致你输入法不能正常使用。 设置了GTK_IM_MODULE之后呢？假设匹配到对应的im module，就会使用对应的im module，假设没匹配到，那就返回之前的没有设置的情况。 LC_CTYPE和设置*_IM_MODULE两种方式我偏好后者。 这里还有个很脑残的问题，GTK一定会去读取 /etc/gtk-2.0/gtk.immodules （按发行版，和cpu架构，以及gtk版本可能不同）里面记录的im module，尽管gtk-query-immodules-2.0和gtk-query-immodules-3.0是可以自己查询的。所以打包者必须自己在安装后脚本内更新这些文件。可能当初Gtk想做缓存……不过现在这年头不缓存也没啥大不了的了。 回到 Qt 这边，情况稍好，首先挑选规则还是如之前所述，按语言。但如果没有环境变量QT_IM_MODUE的干预，这个可以通过 … Continue reading
关于 Fcitx 的用户一些非常想说的话
1、4.x 之后不要问怎么改配置文件。fcitx-configtool 和 kcm-fcitx 是你的朋友。我虽然熟知如何手动修改配置，但别指望我会告诉你们。 2、不要争论关于依赖的问题。 你洁癖你自己靠边站。况且依赖也不多嘛。 3、请用 IM Module，在Ubuntu，Debian上这个包叫做 fcitx-frontend-{gtk2,gtk3,qt4}，我已经要求打包者默认安装fcitx的时候安装这些（目前还只默认装 gtk2 gtk3）。在 Fedora，OpenSUSE，Chakra，Archlinux上这个包叫做 fcitx-{gtk2,gtk3,qt4} 4、我在 Issue 的默认模板那里也写了 http://fcitx.github.com/handbook/chapter-config-env.html http://fcitx.github.com/handbook/faq.html 这两份文档是你不能正常使用 Fcitx 的时候应该阅读的。可以自我检查配置是否正确。（附带一提，Ubuntu 11.10 里面 im-config 带的 fcitx的配置只能把fcitx配置成使用 xim，debian sid 里面的im-config已经修改了……如果你要用 4.1 + 的版本的话，so，要么你手动改 /usr/share/im-config/data/80_fcitx.im 里面把xim改成 fcitx，然后im-config，要么用第一个链接的后半部分 (有关 ~/.xprofile) 自行配置） … Continue reading
今天用上了Qt 4.7
心之兄早就提到了，今天由于qt 4.7进testing源了，所以升级了试试。 raster的速度感觉像是在抽风啊。二话不说把blur给开开。glxgears的数字表明确实很给力。 太给力了。 不过最给力的还是伪粗体。原来systemsettings里面有这么多地方都是粗体啊。今天才知道。 qt你太给力了。
KDE和Gnome主题架构对比
纯粹是回帖越写越长，最后决定还是在自己的blog保留一份。和原文相比略有修改，修改了一些错字和不太恰当的描述，加了一些图辅助说明，算是一篇比较认真制作的文吧。 kde的ui toolkit是qt，gnome的ui toolkit是gtk，所以下文很多地方直接使用了gtk和qt。 先说窗口边框，metacity，kwin，compiz各有不同。 metacity支持自己的主题，可以用文件配置。kwin则是从代码级别上支持主题，新主题就需要写个新代码，compiz的emerald和 metaciy类似不谈。所以如果想让kwin和metacity和emerald类似，那么就需要有个kwin的边框引擎支持从图片或者什么其他的配置，kwin目前官方有aurorae这个引擎，支持直接从kde-look下载，通过svg图片配置。 kwin的各个主题，都是需要独立实现的 高度集成的aurorae，从kde-look直接下载 界面的话和qt和gtk又有不同，gtk支持界面每个部件使用不同引擎，统一用gtkrc管理，而qt的界面是单一引擎，配置都是各个引擎自己独立配置，各有自己的配置文件，再外加上colorscheme组合出各种颜色。 gtkrc样例 colorscheme配置，注意里面的获取新方案，我十分心水kde和kde-look的高度集成 plasma的话位置在~/.kde/share/apps/desktoptheme下面，都是svg文件，其中连文字边距等等信息也都是通过 svg实现的。auroae的边框引擎是基于plasma的，所以也是svg，在~/.kde/share/apps/auroae下面，和 emerald，metacity的多个分着的png不同，基本是一个整体的svg，编辑门槛比较高一些，但是好处就是svg是矢量，做出来的主题在缩放之后有更好的支持。 plasma主题选择，依旧支持kde-look直接下载安装 总结来看，就是gtk引擎的组合相对更加自由，qt更加固定，容易让开发者做出那种整体协调的主题。例如oxygen，bespin这种整体超级协调的引擎。当然qt也有qtcurve这种超等级高自定义的引擎，几乎可以拿来模拟任意gtk主题，外加qtcurve同时也实现了gtk引擎，qt和 gtk程序统一界面也很容易。qtcurve的另一个优点就是可以用gui配置，简单易用，而gtkrc没有编辑工具（据我所知）。 另外qt原生支持gtk主题，这点比起gtk的态度貌似好很多…… qtconfig中配置gtk主题 kde中配置gtk风格 P.S. 截图来自kde4.5rc3，如果你很奇怪你的kde为什么界面不一样，那么说明你应该考虑更新一下。
纠结的XIM，兼对GTK吐嘈
恐怕ibus和scim要偷着乐了，作为fcitx开发人员之一，当然要秉持fcitx的特点，轻量级，依赖少，可是最近稍微研究了一下XIM（把fcitx的debug打开），我对各大公司搞出的重量级应用程序开始有些愤恨… 就拿firefox来说吧，当然我现在还不大了解XIM本身的机制，因此可能有些妄断。XIM的交互是一个很老很老的库写的（copyright都93,94年）了，似乎到现在也没有成为标准的感觉。好，且不说这个，fcitx在firefox当中输入时第一次输入是不会光标跟随的，为什么呢？我其他Qt程序都运行的好好的嘛，怎么会有这个问题呢？好吧，于是我安装ibus玩一玩，我叻个去，如果GTK_IM_MODULE设置成xim，比fcitx还悲剧咧，我今天终于深刻感受到，gtk，就数你最不是好鸟，qt我这里怎么都work的完全ok啊，我的KDE程序没有一个不工作的好好的，结果你还害的firefox等等诸多程序一起悲剧。今天我也用ibus，不用gtk module玩了一把gnucash，也一样悲剧，结论就是，大部分的GTK的程序都在冲你吼叫XIM去死吧。大家说，ibus什么的输入没有问题，其实不是咱的过错，linux输入法至今感觉依旧混乱，qt的im module虽然也有，不过不知道是不成气候还是怎么样，xim和qt依旧和谐。 吼你就吼好了，你自己去成为一个更好的标准啊，大家皆大欢喜？好嘛，最后还不是大家一起杯具。 再说起外观这个事情，Qt好心好意的说，来来GTK，我也能和你长得一样哦，结果GTK似乎完全不鸟这个嘛，一个能用的Qt engine都没有（都是好心的人在kde-look上搞得，基本都不成熟，也难怪啦）。 喂喂gtk小同学你是不是吸取了c××××精神搞起独×了…… 最后为了皆大欢喜，我决定把gtk immodule实现提上日程。 以上
