在OSD Lyrics中，我使用以下代码，来实现鼠标穿透功能：

  gdk_drawable_get_size (osd->osd_window, &w, &h);
  GdkPixmap *input_mask = gdk_pixmap_new (NULL, w, h, 1);
  GdkGC *gc = gdk_gc_new (input_mask);
  GdkColor color;
  color.pixel = 0;              /* black */
  gdk_gc_set_foreground (gc, &color);
  gdk_draw_rectangle (input_mask, gc, TRUE, 0, 0, w, h);
  gdk_window_input_shape_combine_mask (osd->osd_window, input_mask, 0, 0);
  g_object_unref (input_mask);
  g_object_unref (gc);

简单来说，就是生成一个w*h的黑白pixmap，用绘制矩形的方法将它的所有像素置零，然后将它作为OSD窗口的input shape mask，使得在其上的所有鼠标事件都不会被OSD窗口捕捉。

这段代码在之前一直工作很正常，但是最近有人报告说穿透功能失效了。然而这项功能在我的Ubuntu 9.10上很正常，于是我怀疑是与Gnome 2.30自带的GTK 2.20有兼容性问题。

最近把系统升级到了10.04，GTK升级到了 2.20，果然问题出现了。无论color的pixel设为0还是1，都没法产生效果。进一步实验发现，如果去掉gdk_draw_rectangle一句，也就是生成pixmap后不绘制任何东西，那么input mask是可以生效的。一旦在上面绘制矩形，不论怎么绘制，绘制的部分都会没有穿透效果，也就是说，被绘制的部分成了有遮挡的标记。

但是不能直接把绘制矩形的部分去掉，因为在低版本的GTK中，gdk_pixmap_new返回的pixmap并不是所有像素都置零的，也就是mask是一个随机的效果，这也是为什么我在实现的时候要画个矩形。一个比较丑陋的解决方法就是判断GTK的版本，如果版本小于2.20，就绘制矩形，否则不绘制。这个方法很恶心，而且天知道新的GTK出来后会不会出问题，至少在文档中没有对gdk_pixmap_new返回的pixmap作任何保证。

后来想到notify-osd在lucid下鼠标穿透的功能依然正常，查看了它的代码，发现对input_shape部分进行了大幅地修改，参考之后代码修改为如下形式：

  GdkRegion *region = gdk_region_new ();
  gdk_window_input_shape_combine_region (osd->osd_window, region, 0, 0);
  gdk_region_destroy (region);

就是创建一个空区域，然后将它作为input shape，因为是空区域，所以整个OSD窗口都是镂空的。

虽然问题解决了，但是还是不明白，为什么之前的方法在GTK 2.20上不能用了（应该说是在GDK 2.20上不能用了），2.20在input shape mask和pixmap上有什么改动，上面的代码要作什么改动才能正常工作呢？如果有朋友知道，请告诉我:)

OSD Lyrics 是一个第三方歌词程序，它能为Linux下的多款播放器提供类似Windows下QQ音乐的歌词显示功能，并能自动从网络上下载歌词。

这次的0.3.20100330带来了一项重大更新和几项小更新。

OSD Lyrics 是一个第三方歌词程序，它能为Linux下的多款播放器提供类似Windows下QQ音乐的歌词显示功能，并能自动从网络上下载歌词。

OSD Lyrics当前支持Amarok、Audacious、Banshee、Exaile、MOC 2.5、 Quod Libet、MPD、Rhythmbox、Songbird、XMMS2，可以从搜狗或千千上下载歌词。

自 OSD Lyrics 0.2 版发布以来，已经过了快半年了。在这半年里，OSD Lyrics 有了不小的进步。在新年到来之际，我认为积累的改动足以把版本号加上0.1了（简单来说，因为过年了，所以版本升级了:)）。

今天OSD Lyrics添加了第10个播放器支持——Quod Libet。Quod Libet的支持有些不完善的地方，主要是：

• 不支持停止——因为Quod Libet里根本就没这个概念
• 不支持跳转到指定时间——它的dbus接口没有提供这一选项。虽然现在用不到，不过很快就会有功能要用到它了
• 不支持获取播放文件的地址——也就是说，不能根据音乐文件地址来查找歌词了

不过Quod Libet似乎要支持MPRIS，如果支持的版本出来了，那么就可以完美了

什么是 Emacs daemon

关于Emacs有一个很著名的笑话，就是Emacs = Emacs Makes A Computer Slow。Emacs启用慢是一个人尽皆知的事实。由于启动时要加载大量的脚本和插件，使得Emacs在启动时往往需要数秒之久。因此我在进行一些快速简单的任务，如svn commit时，都是使用nano或者vim来进行的。

Emacs daemon就是为了这个而诞生的。它将Emacs变成了一个C/S模型——只需要启动一个服务器在后台作为守护进程（daemon）跑着，之后启动的每个emacs都是一个客户端，它连接上服务器进行工作。这样一来，只要在启动服务器时运行初始化脚本，客户端启动无需运行脚本，实现启动时间从Firefox到Chrome的转变。

使用 Emacs daemon

要使用Emacs daemon，至少需要Emacs 23。它提供了一个emacsclient程序，用于启动客户端。

有客户端就必然要有服务端。要启动一个daemon，需要在运行emacs时加入一个--daemon参数。幸运的是，我们不用手动启动服务端，而是可以利用emacsclient的-a参数。emacsclient的-a参数用于指定连接不上服务器时使用的别的编辑器（alternate editor），当把这项留空时，它会自动启动服务端。如果不想指定-a，也可以将ALTERNATE_EDITOR环境变量设为""。

除了-a参数，emacsclient还要手工指定使用终端还是X来启动。要从终端启动，需要使用-t参数：

emacsclient -t -a ""

从X启动则是-c：

emacsclient -c -a ""

方便些，再方便些

每次都要输入上面那些命令太烦了，不符合*nix的终极目标——偷懒

首先把终端版本设一个alias。编辑~/.bashrc，在最后加入

#用ec来快速启动emacs client
alias ec='emacsclient -t -a ""'
#现在可以将emacs设为默认编辑器啦:P
export EDITOR="ec"

以后在终端下输入ec就可以启动emacs的终端客户端了:)

在X下，我习惯用gnome-do来启动程序。因此最方便的方法就是建立一个菜单项，名叫Fastmacs，内容自然就是X模式启动emacsclient的命令啦

配置，还是配置

俗说说得好，.emacs说有多少就有多少+1。如果在.emacs里对X相关的选项（字体什么的）直接进行设置，那么会发现用emacsclient启动时，这些设置都失效了。这是因为这些设置是在X下的frame创建时才有效的，而启动服务器的时候是没有创建frame的。

解决方法有两种，一种是使用after-make-frame-functions这个hook，在创建一个frame之后才进行设置。代码如下

(defun frame-setting ()
    (set-frame-font "文泉驿等宽微米黑 8")
    (set-fontset-font "fontset-default"
		      'gb18030 '("文泉驿等宽微米黑" . "unicode-bmp")))

(if (and (fboundp 'daemonp) (daemonp))
    (add-hook 'after-make-frame-functions
	      (lambda (frame)
		(with-selected-frame frame
		  (frame-setting))))
  (frame-setting))

需要判断是否以daemon模式启动，分别进行处理

另一种方法是设置window-system-default-frame-alist，直接设置参数的默认值

(setq window-system-default-frame-alist
      '(
        ;; if frame created on x display
        (x
	 (menu-bar-lines . 1)
	 (tool-bar-lines . nil)
	 ;; mouse
	 (mouse-wheel-mode . 1)
	 (mouse-wheel-follow-mouse . t)
	 (mouse-avoidance-mode . 'exile)
	 ;; face
	 (font . "文泉驿等宽微米黑 8")
	 )
        ;; if on term
        (nil
	 (menu-bar-lines . 0) (tool-bar-lines . 0)
	 ;; (background-color . "black")
	 ;; (foreground-color . "white")
	 )
	)
      )

可以设置的参数见Emacs Lisp Reference > Frames > Frame Parameters

推荐使用第二种方法，启动客户端时直接就使用所设置的字体了

参考文章

http://www.wanglianghome.org/blog/2009/01/customization-tips-for-emacs-daemon.html

http://jackycxh.blog.35.cn/2009/07/22/emacs-daemon-and-font/

update：发现还需要禁用entrust的证书，但是entrust被内建在chromium里了，有什么办法能禁用它呢……

这就是所谓的“老鼠过街，人人喊打”吧。

废话少说，进入正题。由于Chromium在Linux上使用的是系统的证书，所以要使用系统自带的工具来清除。

具体方法参考自http://code.google.com/p/chromium/wiki/LinuxCertManagement

安装工具

Ubuntu/Debian：

sudo apt-get install libnss3-tools

 Fedora：

su -c "yum install nss-tools"

Gentoo：

su -c "echo 'dev-libs/nss utils' >> /etc/portage/package.use && emerge dev-libs/nss"

Opensuse：

sudo zypper install mozilla-nss-tools

列出证书

certutil -d sql:$HOME/.pki/nssdb -L

在我机子上结果如下：

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI
…………………………
Starfield Secure Certification Authority #2                  ,,   
CNNIC SSL                                                    ,,   
VeriSign, Inc.                                               ,,   
……………………

删除证书

将CNNIC赶出系统：

certutil -d sql:$HOME/.pki/nssdb -D -n "CNNIC SSL"

完成后再列出证书，可以发现没有CNNIC的身影了。

重启Chromium，登录CNNIC认证的一个网站：www.enum.cn/en/，是不是已经不受信任了？

一些补充

• 在Gentoo下，要将certutil命令改为nsscertutil
• 此方法只是删除CNNIC证书，目前我并不清楚它会不会又回到系统中。如果有将其彻底屏蔽的方法，请告诉我

忙了一个多星期，终于把这个版本给弄出来了

没有什么新功能增加，只是修复了一个严重的bug：下载歌词时，如果网络不好导致DNS超时，OSD Lyrics 100%会崩溃。

Bug原因很清楚，也很严重，之所以拖了那么久才解决，是因为修复这个bug要伤筋动骨一番。最后把歌词下载模块改成了多进程方式，这回应该可以根除它了。

另外根据zuolun同学的建议，提供文字轮廓宽度调节选项。

在用多进程下载模型可耻地失败之后，OSD Lyrics使用了多线程模型来对歌词进行下载。在完成之后发现每当DNS超时时，程序都会崩溃。经过不断地调试，确定是curl的问题。看了文档后发现，原来curl在多线程环境下，由于DNS查找超时是使用信号实现的，所以在多线程环境下是不安全的。当时想了两个方法：在自己的程序里包含curl，启用异步DNS查询cares；或者大幅修改程序，使用curl的异步查询接口重写下载引擎，把程序重新变成一个单进程、单进程的程序。第一种方法会让代码的大小和编译时间大幅增长，第二种方法要把两个下载引擎（搜狗和千千的）给大幅改写，过于复杂。于是一直纠结……

后来请教了 @henry_ 老师，一句话把我打回原点——用多进程才是王道。

进程vs线程

重新审视自己的设计和多进程模型失败的原因：因为在子进程中使用了X的操作。为什么会有X的操作呢？看看下载一个歌词的步骤：

1. 搜索歌词，并将搜索结果返回
2. 如果有多个搜索结果，弹出选择窗口
3. 下载选中的歌词
4. 下载成功，显示歌词

之所以会有X操作，是因为第2步弹出了一个窗口。由于子线程同样不能操作GUI元素，因此多线程模型同样要在主线程中处理弹出窗口。我在设计中将下载过程给模块化了，有一个专门的下载模块，将具体的下载引擎和主程序分开。线程化后的下载过程是这样的：

1. 主程序向下载模块注册搜索和下载回调函数
2. 主程序发起搜索请求
3. 下载模块建立搜索线程，搜索线程调用下载引擎的搜索函数，返回后唤醒下载模块在主线程的回调函数
4. 下载模块的回调函数调用所有注册了的搜索回调函数
5. 主程序的搜索回调函数弹出选择窗口
6. 下载模块建立下载线程，下载线程调用下载引擎的下载函数，返回后唤醒下载模块在主线程的回调函数
7. 下载模块的回调函数调用所有注册了的下载回调函数
8. 主线程的下载回调函数显示歌词

也就是说，只是将原来的第1步和第3步线程化了，而这两步是没有X操作的。而且由于将下载过程都放在下载模块里了，因此多线程部分完全是在下载模块里实现的，主程序和下载引擎一点也不知道多线程的存在。

既然如此，为何不讲它们进程化呢？把实现中的线程改成进程，就是多进程模型了。一旦这样做的话：

• 子进程中没有X操作
• 只需要修改下载模块，主程序和下载引擎不需要修改，工作量小，不易出错
• 多进程不会再有信号的问题。更进一步来说，子进程你爱挂就挂吧，对父进程半点影响都没有，多健壮啊
• 进程之间没有公共数据，无需同步，不怕数据修改
• 我管你子进程怎么分配内存，反正一退出全回收了
• ……………………

明白自己要什么

首先搞清楚自己需要怎样的多进程操作：

• Unix的fork风格
• 异步函数调用形式，在fork时指定回调函数，子进程退出后自动调用回调函数
• 子进程能返回数据到回调函数中，不只是退出状态

简单来说，就是要一个刚好能替代现有线程操作的方案，而且它是和现在的线程操作类似的，这样使用起来直观，而且修改难度小。

然而我遇到了一个问题。

如何从子进程中返回数据

从子进程中返回数据的问题思考了很久，因为进程间通信不像线程间通信那么简单，直接传一个指针完事。@henry_ 老师给我指明了两条路：使用管道或共享内存。

就此思考了一番。管道需要将返回数据序列化，再通过管道传送，最后反序列化还原数据。共享内存不需要序列化，但是需要自己管理内存，而且不知道要开多大的共享内存，内存的分配与释放都要仔细考虑。

最后的决定是使用管道。虽然要实现序列化操作，但是过程简单清晰。如果使用共享内存，那么设计会变得很复杂，容易出错，而且内存相互分离的优点也没了。

具体设计

把一切都想清楚之后设计就很清晰了。

• fork前打开管道
• fork时指定回调函数
• 子进程使用管道写入数据，然后退出
• 父进程从管道读入数据，然后调用回调函数并将数据传入
• fork模块只负责传递数据，不负责序列化操作

最后的设计只有一个函数：

pid_t ol_fork (OlForkCallback callback, void *userdata);

回调函数的定义如下：

typedef void (*OlForkCallback) (void *ret_data,                                                                                  
                                size_t ret_size,                                                                                 
                                int status,                                                                                      
                                void *userdata);

同时，为子进程提供了用于返回数据的文件描述符和文件流：

extern int ret_fd;
extern FILE *fret;

实现细节

剩下的最大问题就是如何在子进程退出时调用回调函数了。最直接的想法就是处理SIGCHLD信号。由于不同的子进程可能需要调用不同的回调函数，也有不同的用户数据，因此需要有一个子进程ID和回调函数的对应表。感谢GTK、GDK、GLib，现在只需要用g_child_watch_add就一切都搞定了。

关于序列化，本来是想用protobuf的，它的C绑定似乎还直接提供了RPC的支持。由于我只是简单的需要一个IPC的数据传递，干脆自己写一个来练手好了。

序列化的协议很简单。因为只有两种结构需要序列化——数组和结构体，所以就简单地定义了一下。对于结构体，将其字段按一定顺序输出，以换行符间隔。对于数组，先输出一行总数，再输出各元素，每个元素后再加上一个换行符。由于是程序内部用的IPC数据，因此只要单元测试通过了，数据的正确性就可以完全信赖，不需要复杂的容错机制。

一些弯路

一开始在考虑子进程返回的触发时，@henry_ 提示可以用select或者poll。实现了之后发现有两个问题，一是如果子进程的返回数据是分段输出的话，回调函数可能会调用几次，每次收到一段数据；二是如果子进程没有返回数据（也就是返回数据为空），那么回调函数根本就不会运行。因此还是老老实实采用子进程退出来触发回调函数。

开始的设计是向回调函数传递一个fd，让回调函数自己读取数据。这么做是为了能让回调函数利用fgets来读取一行。思考之后觉得这样很不自然，而且回调函数要考虑的东西反而多了，复杂了，于是改成了现在这个样子。

在实现序列化的时候没有想清楚，把不需要序列化的OlMusicInfo给序列化了，白做工了。

在反序列化结构时，一开始是返回true or false，后来发现一个问题，就是在反序列化数组时，不知道一个元素反序列化后，剩下未被反序列化的数据从哪开始。于是把接口改成了返回指向剩下数据开头的指针，如果失败就返回NULL。

结论

把fork模块和序列化做好之后，修改代码就很简单了，只需要把对应的地方改一下，程序很欢快地跑了起来。

使用多进程的设计，避免了修改curl使用方式的缺点，而且使得程序更健壮。由于Linux轻量级进程的优势，多进程和多线程的性能应该没有太大的差别，而且实际上下载也不是程序的瓶颈。

此次设计进行了仔细考虑，而没有像之前边做边迭代的方法。在明确自己的目标，排除多余的东西，对各方面作出权衡和折衷之后，得到了一个比较简洁的接口和实现，自己觉得还是很满意的。

实现的过程中对新的代码做了充足的单元测试，发现了一些问题，同时修正了设计，最后用起来自己也相当放心。在代码不是立刻可以整合到系统中的时候，单元测试往往是能立刻看到成果的方式，而且也能检验自己的设计是否合理。

从多进程到多线程，最后又回到多进程，貌似绕了个大弯又回到原点。但是这两个多进程的设计高度完全不一样。在实现了多线程机制后，对整个下载的过程和实现有了充分的了解，现在的多进程流程也是在多线程的设计中定下的。如果没有多线程模型这个探索，也就很难有现在这个设计。所谓螺旋式上升嘛，说不定以后又会改成多线程，但是可以肯定的一点是，一定会比现在的要更好。