Tools
“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 版本我都没完全放弃，可用着用着还是发现不对劲，就是我的邮件经常会莫名奇妙的消失，比如收邮件时时，我把一封邮件从 [...]
开发了将近两周的一个项目终于可以称作正式发布了: 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 下代码做出贡献哦。
Mac OS X 10.5 中，由于 Scripting Bridge 的引入，用 Ruby 或 Python 程序完成原来 AppleScript 才能完成的任务变得非常简单，而因为这两门语言自身的强大，无形中，可以完成的工作也多了不少。比如我们原来可能要用 ID3Mod 这样的软件进行 iTunes Music Library 的歌曲乱码转换，现在写一段不到十行的 Python 脚本就能完成 (当然，界面没有那么方便)。
一个小例子
这里先用 Python 简单的展示一点可以完成的操作:
# 导入必要的模块 from Foundation import * from ScriptingBridge import *
# 找到 iTunes 这个应用程序 iTunes = SBApplication.applicationWithBundleIdentifier_(”com.apple.iTunes”)
# 打印出当前正在播放的音乐名称 print iTunes.currentTrack().name()
这段代码在 Leopard 下，既可以保存为 .py 文件，用系统自带的 python 解释器 (/usr/bin/python) 执行，也可以直接在命令行下调用 Python 解释器，查看它的输出，比如我这里是:
$ python Python 2.5.1 (r251:54863, Oct 5 [...]
众所周知的是，vim 的代码是 Bram 用 patch 的方式维护的，一种典型的集约式管理，虽然 edyfox 在 https://vim.svn.sourceforge.net/svnroot/vim 维护了 svn 版本，但这也只是导入 CVS 的内容而已，别人无法往里面加入代码，问题是，当你想开发一系列试验性功能时，没法直接在 vim 的 svn 仓库上工作 (比如创建分支)，而只能用自己的版本管理仓库。
这便造成了一个显然的维护问题，以我自己为例，vim-cocoa 的代码原本使用 code.google.com 提供的 svn 服务进行维护，但 Subversion 是以目录为单位跟踪修改的，所以，同一个代码目录，要么来自 vim 的代码仓库，要么来自 google code 的代码仓库，二者不可兼得。
所以我原来使用了一套非常麻烦的维护方式:
$ svn co https://vim.svn.sourceforge.net/svnroot/vim/vim7 $ cp -r vim7/ vim-cocoa/ $ cd vim-cocoa; find . -name “.svn/*” -exec rm -rf {}; $ svn import src/gui_mac.m https://vim-cocoa.googlecode.com/gui_mac.m …
也就是说，抓下一份 vim 的代码来，复制一份，去掉其 svn [...]
© jjgod / blog. Powered by WordPress using the DePo Skinny Theme.