Tag Archives: qt

如何给 Qt 贡献 Patch

最近给 Qt 5 写了几个傻瓜都能写的 Patch ……目的是修复一些输入法相关的 Bug。当然这不是重点,重点是怎么给 Qt 写 Patch 并提交。 首先 Qt 自从转向开放管理之后,给 Qt 写 Patch 就成为了一件非常简单的事情。 首先不用说,你需要注册个账号,先到这个网站注册个账号,bugreports.qt-project.org,然后打开codereview.qt-project.org ,选择 sign in,sign in之后需要做的就是和一般的代码管理网站一样,添加你的ssh key,然后还需要做的是签署一个协议,在Agreements里面,作为一般人签个 Invidudual的就好,另一种是如果你代表公司向 Qt 贡献,那么则是签那个,然后大概就是需要等这个审核通过,效率还是非常高的,喝口茶大概最多几个小时之后就ok了,然后你就可以通过 gerrit (qt的code review 系统提交 patch 了)。 gerrit 这个东西是个非常神奇的东西,非常好用,如果你熟悉 git 的开发的话就更好了。 其实 Qt 上已经有了非常详细的说明,我这里只简单介绍一下。 … Continue reading

Posted in Qt | Tagged | 4 Comments

输入法环境变量的故事

有时候我想想,我是不是应该写一些比较普及的文档(你懂得,我特意纠结了一下措辞)。 那么这次先来介绍一下关于输入法的环境变量配置问题: 在远古时代,世界一片混沌,那时世界上还没有 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

Posted in fcitx development | Tagged , , | 11 Comments

关于 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

Posted in fcitx development | Tagged , , , , , , , , , , , | 25 Comments

今天用上了Qt 4.7

心之兄早就提到了,今天由于qt 4.7进testing源了,所以升级了试试。 raster的速度感觉像是在抽风啊。二话不说把blur给开开。glxgears的数字表明确实很给力。 太给力了。 不过最给力的还是伪粗体。原来systemsettings里面有这么多地方都是粗体啊。今天才知道。 qt你太给力了。

Posted in KDE, Qt | Tagged , | 18 Comments

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为什么界面不一样,那么说明你应该考虑更新一下。

Posted in KDE | Tagged , , , | 5 Comments