A personal web log, by Jjgod Jiang.
Archive for December 2007
To make developers’ lives easier, Apple really should make the following 6 frameworks bundled with their OS, it will make application distribution much better.
我在页面下方加入了两个小按钮，分别接受 RMB 和 USD 的捐赠，如果你对下面任一关键字有兴趣:
而且希望见到它们得到更好的开发，可以考虑给我一点鼓励，捐赠将用来购买书籍、设备和支付参加会议的费用 
不过不管有没有捐赠，我都只能按照自己的时间和计划来工作 (yep, 这和 vim 的 sponsor 政策差不多)。
“All mail clients suck. This one just sucks less.” - The mutt slogan
邮件客户端 (又称为 MUA, Mail User Agent) 似乎是一切用户永远的怨念，因为实在太难找到一个合意的了，这里“一切用户”当然也包括我，事实上，我寻找合适邮件客户端的路程也极为曲折。
自从 1997 年接触网络的时候申请了第一个 (163.net 的) 电子邮箱，当时因为网络太慢，大家都拨号，访问 163.net 花哨的 web 邮局界面登录一次就得等半天，实在太也奢侈。于是研究了半天，参照当时杂志上推荐的 Foxmail 配置了一下，记不得是哪个版本了，当时倒还是挺满意的，于是 Foxmail 伴随我的邮箱由 163.net 到 21cn.com 这么用下来，现在在 Windows 平台下也不失为一个可以考虑的选择。
不过作为一个喜欢排版的人，眼睛总是挑剔的，Foxmail 令我感到恼火的就是你很难选择合适大小的中文字体，众所周知 SimSun 的 9pt, 10.5pt 和 12pt 最佳，可 Foxmail 的选择偏偏跳过了这几个，缺省是一些非常恶心的大小，仅因为这一点，令我非常不爽，于是乘着 Thunderbird 1.0 顺利发布的东风，换成了 Thunderbird。
Thunderbird 也用了挺长一段时间，直到 2.0 版本我都没完全放弃，可用着用着还是发现不对劲，就是我的邮件经常会莫名奇妙的消失，比如收邮件时时，我把一封邮件从 Junk Mail 区拖回到 Inbox，结果收完了邮件 Inbox 里和 Junk Mail 里都找不到这封邮件了！自从 Thunderbird 搞丢我一封重要邮件后，我永久地放弃了 Thunderbird。
放弃了 TB 用什么呢？幸运的是，GMail 横空出世了，一开始也不觉得 GMail 有多好用，无非是大一点，不用删除，但后来用着用着就把所有的邮件都放到了 GMail 的 web 界面中去处理了，为什么呢？
于是 GMail Web 界面成为了我主要的邮件处理工具，一直用到现在，虽然也积累了一些小的怨念，但还没有大到让我换客户端的程度，包括:
其实最大的原因还是始终找不到合适的客户端，以前 GMail 不支持 IMAP，本地收下来的信和别的地方无法同步，这是完全不能忍的，而自从 GMail 开始支持 IMAP 一来，我试用了:
直到昨天，alpine 的 1.00 版本发布，我终于看到了一个比较可以接受的替代品，alpine 是纯字符界面，满足我对编辑和查看邮件的要求，配置比 mutt 简单得多，也不需要额外安装什么专门用来发信收信的工具，IMAP 支持很不错，甚至连邮件 header 都不需要全部下载就能浏览 INBOX，这一点其它客户端似乎都办不到。唯一的缺点是 thread 组织比 sup 的做法还是差了许多。
我还在试验，学习中，如果遇到什么问题，也许会尝试自己去改进 (当然，只要有时间)，真正“完美”的邮件客户端也许能找到，也许找不到，但寻找的过程本身就很耐人寻味，或许邮件客户端从发明的那一天起，就是要我们学会适应与妥协吧？
把寻找的过程写下来，希望能对别人有用。
开发了将近两周的一个项目终于可以称作正式发布了: Mac Dictionary Kit 的目标是成为一套在 Mac OS X 系统下常用的词典处理与转换工具。虽然在目前它只支持 stardict 格式的转换，但相信随着以后代码的抽象和新格式需求的增加，我们会支持更多的格式，以及更强大、更复杂的转换功能。也尽可能提供更方便的图形用户界面。
目前 MDK 以两个子项目的形式发布: sdconv 是独立的命令行方式转换工具，专门用于 stardict 词典格式到 Dictionary 2.0 词典格式的转换；DictUnifier 是一个图形界面转换工具，它的设计是为了自动探测并支持多种来源格式，虽然目前它也只支持 stardict 格式。
发布在 Google Code 上，主要是为了提供更好的下载服务、更详细的文档和 bug 跟踪。因为这个项目原来参考了 stardict 的代码，所以沿用 GNU GPLv2 发布。
目前，这两套工具提供的都是 Universal Binary，支持 Intel 和 PowerPC 的 Mac 机器。也都是绿色软件，只需要解压/挂载就可以使用。
在这两套工具正式发布之前，得到了水木社区 Apple 版许多版友的测试与 bug 报告，在此表示诚挚的谢意。
这两天做了一些 Nally (MacBlueTelnet) 的修改，主要是让它支持 GBK 编码的 BBS。如果你经常在 Mac 下上 BBS，又对现有的客户端 (Terminal, iTerm, AlienBBS) 的显示正确性/速度/文本渲染效果不满意，可以试一试 yllan 开发的这个 Nally。最大的优点就是用 Core Text 渲染文本，速度特别快，而且字体选择方面专为中文 BBS 优化。我自己已经用它替代使用了很长时间的 iTerm 了。
另外，这是一个开放源码的项目，你也可以用 subversion checkout 下代码做出贡献哦。
wine 虽然声称自己是一个跨各平台的项目，可是它的 Mac OS X 支持一直很糟糕。因为最近 ie4osx 的出现，原本对 wine 不感兴趣的人，如我又开始活络起来。今天花了一点时间理了理 wine 在 OS X 上的几个问题，简单记录如下，也许对别人有用。
首先，wine 原本是不支持 Mac OS X 的，但独立的 Darwine 项目很大程度上解决了这一点，可是 Darwine 项目自从去年十月份一来就再也没有更新过了，也没有给 x86 的二进制包发布。最近 ie4osx 的编译者提供了二进制包的下载，其实是来自这里编译的，然而这里提供的安装包中能用只有 x11drv，也就是说，wine 必须依靠 X11 才能运行，不能脱离 X11，像一个 native 的 OS X 应用程序那样运行。
原本 quartzdrv 也是 Darwine 项目中的一个分支，目标就是实现 native 的 OS X 支持，可惜出师未捷身先死，quartzdrv 目前也不能和最新的 wine 代码很好的兼容了。然而事实上，依赖 wine 开发的 CrossOver Mac 这个项目早就完成了 quartzdrv 的改定，只不过这是一个商业项目，修改后的代码并没有公开，甚为遗憾。
所以一个好用的开源 quartzdrv 实现就成为了一直悬而未决的开发难题，现在 wine 的 git tree 中虽然有部分残余，其实是去年 Pierre d’Herbemont 发到 wine-patch 邮件列表的一系列 patch 中的第 1, 2 个，后续的 patch 一直未能合并进去，然而我咨询 Pierre 得到的回答是，他发的这一系列 patch 的功能仍然不能补足整个 quartzdrv 的需要。
我强烈建议有兴趣的同学，把这个开发的想法作为明年 Google Summer of Code 的项目。
话说回来，基于 X11 的实现在 Leopard 下会有一个 IE 页面频繁刷新的问题，通过更新 X11 到 2.1.0 版本可以解决。
上周末参加 thossclub 的讨论，对各平台文本排版与渲染技术做了一个简短的介绍，这个介绍的 slides 可以在这里下载: text-rendering-tech.pdf (6.1 MB, PDF)
近来在开发一个小软件，需要分发程序链接了一些用 macports 安装的库，众所周知，用 macports 安装 universal binary 程序是通过 +universal 这个缺省 variant 实现的。在默认情况下，显然用户不愿意安装 universal 的，既然都在自己机器上编译了，去编译其他平台的二进制程序即浪费时间又浪费空间。所以默认这个 variant 是禁用的，可是如果你自己开发的 Universal Binary 应用要链接用 macports 安装的那些库时，就必须首先确保这些库是 universal binary。
可是在 10.5 下通过 +universal 之后，链接程序会遇到类似下面的错误:
$ sudo port install gettext +universal
...
---> Building gettext with target all
Error: Target org.macports.build returned: ... returned error 2
...
gcc -dynamiclib -o ... -L/opt/local/lib -lc
-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386
-arch ppc -arch i386 -arch ppc -Wl,-framework -Wl,CoreFoundation
-install_name /opt/local/lib/libintl.8.dylib
-compatibility_version 9 -current_version 9.2
ld: library not found for -ldylib1.10.5.o
collect2: ld returned 1 exit status
...
这是什么原因呢？仔细看最关键的地方在于，macports 缺省使用了 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc 这个编译器参数来生成，可是在 Mac OS X 10.5 下，如果仅仅使用这个参数，系统仍然会以为你要编译的是 10.5 下运行的程序，所以最后会尝试链接 10.5 的 libc，问题是 10.5 的 libc 在 10.4 的 SDK 路径下当然找不到，于是就出错了。参考 Xcode-Users 上的讨论。
怎么解决呢？也简单，加上 -mmacosx-version-min=10.4 这个编译参数就行了。不过对于 macports 来说，在哪儿加倒是一个问题，你可以针对每个 port，在 Portfile 里加上:
configure.universal_cflags-append "-mmacosx-version-min=10.4"
也可以一劳永逸地通过修改 /opt/local/share/macports/Tcl/port1.0/portconfigure.tcl 脚本中的 default configure.universal_cflags 实现，这里是一个简单的 patch。
这个 patch 已经发到了 macports 的 trac 上，希望能尽快在官方版本中得到修复。