Category: Mac

vim-cocoa 0.3 beta 1 released

After two days of work, here is the first beta of the 0.3 series of [vim-cocoa](http://code.google.com/p/vim-cocoa).

vim-cocoa 0.3b1 screenshot

#### What’s New?

* Updated vim to 7.2.49
* Use Core Text to replace ATSUI for text rendering
* Optimize program startup
* Support transparency option to control background transparency
* Fix cursor redraw on right clicking
* Fix CTRL + SHIFT + ? key handling ( Issue 35 )
* Mac OS X 10.5 only (Since Core Text is a 10.5 only framework)

#### Download

* [googlecode](http://vim-cocoa.googlecode.com/files/vim-cocoa-0.3b1.zip)

#### View Source

* [github](http://github.com/jjgod/vim-cocoa/tree/coretext)

用 Carbon Copy Cloner 复制系统

[Carbon Copy Cloner](http://www.bombich.com/software/ccc.html) 是一套很方便的系统备份工具，昨天试了以下用它把系统完整的复制到另一块硬盘上 (因为买了一块 320G 的硬盘，要换掉 MBP 里内置的 120G 硬盘)。
Continue reading “用 Carbon Copy Cloner 复制系统”

State of iPhone Open Application Development (1)

七月关于 iPhone 的消息一直围绕着 2.0 firmware, iPhone 3G, official SDK 1.0 这几个关键词，而非官方关心的也只是 Pwnage Tool 2.0，却对没有 iPhone Developer Program 的开发进展甚少介绍，我想在这里做一点记录。

随着 SDK 1.0 的正式发布 (遗憾的是，因为 NDA 的存在，甚至它都算不上发布..)，iPhone 2.0 firmware 和 App Store 的上线，在 Apple 监视下的 iPhone OS/Cocoa Touch 程序开发的局限性暴露得越来越明显，saurik, NerveGas 等开发者坚持开发 Open Toolchain 的重要性也越来越明显。为什么在拥有一个如此完善的 SDK 的情况下我们还需要 Open Toolchain 和相关工具？因为:

  • Apple 严格限制了第三方应用对 API 的使用，非 Apple 自己开发的应用程序不能使用许多极为有用的 Private API，否则就是违反 SDK 的授权协议，所以第三方应用始终只能是“二等公民”。
  • App Store 的发行方式要求每次更新软件都要由 Apple 审核才能出现，而列出应用的页面对于用户 feedback 和开发者交流的功能也非常局限——毕竟这个模式根本就是 iTunes Music Store 改头换面了一点点，Album 到 Application 其实并不能做到一一映射。所以我们需要更自由的 iPhone OS 软件发行方式。
  • 软件分发要求所有只开发 Open Source/Free 应用程序的开发者都必须至少缴纳 $99 年费，这极大打击了 Open Source 开发/移植者的积极性，在 Pwnage Tool 的大环境支持下，我们完全可以跳过这个限制，自行分发软件。

因为上面这些原因，我一直非常关注 open toolchain 的开发，到了 4 月份的时候，有半个月的时间一直在跟踪 saurik 在这方面开发的结果，其结果是这篇 Upgrading the iPhone Toolchain，可惜的是因为 saurik 一直不满意用 git 来跟踪上游代码的修改，所以这篇文章其实相当难付诸实施，不过，考虑到 SDK 1.0 的发布后上游代码应该有一个相对稳定期，所以希望 saurik 能够尽快整理出更新的文档和代码来吧。

不过 saurik 在他的 Cydia repo 里提供了 iPhone 上完整的 toolchain，你可以在自己的 iPhone/iPod Touch 上用 gcc 编译，用 gdb 调试…. 当然考虑到有限的硬件资源，这种方式对很多人来说太 geeky 了，包括我。

然而，目前用官方 SDK 提供的编译器和调试器来给编写在 pwn 过的 iPhone 上免费分发的应用程序已经完全可行了，详情可以参考 saurik 的 Bypassing iPhone Code Signatures 和 246tNt 的说明。未 pwn 的 iPhone 因为目前事实上只有通过 App Store 一条路安装应用程序，所以谈怎么分发也是没有意义的。

简单的说，这种方式是因为 pwn 过的 iPhone 的内核已经被打上了 patch，弱化了签名校验——不再要求非要有 Apple 的签名了，可是签名校验依然存在，要完全去掉不大现实，所以现在你可以通过 Apple 自己提供的 codesign 工具来给应用自行签名，或者在别的平台下用 saurik 开发的 ldid 签名工具来保证通过 iPhone 的签名检查。对于大部分 Mac 开发者而言，这也只是在 Xcode 的项目中，新增一个 Build Phase 的事情，所以不会增加什么工作量。

而 246tNt 进一步延展了 saurik 的工作，分析了 entitlements 文件在签名后的 iPhone App 中对安全控制的作用，使得这种自签名的应用程序也能像有 Dev Program 的应用一样，可以用 Xcode 自带的 gdb 进行远程调试。此外，246tNt 还找出了办法对 iPhone OS 中的 SpringBoard 和 MobileInstallation 打上补丁，使得我们可以直接把应用程序用 Xcode Organizer (或者 Build and Go!) 上传到 iPhone 上，并自动开始调试。

感谢这些开发者的工作，目前我们获得的开发环境和支付了 $99 美元的 Dev Program 开发者毫无二致了。可是，分发环境还是有区别，假定我们的程序并没有做任何逾越 SDK 授权的事情，如果还希望通过 App Store 分发，那还是只能去购买 Dev Program。不过毫无疑问，对于开放的应用程序而言，Cydia 应该是更好的分发方式，考虑到因为 Pwnage Tool 2.0 的包含，Cydia 几乎已经成为了标准的应用分发方式。

(待续)

最近在写的两个东西

这两天写了两个简单的小程序，主要是满足朋友和个人需求的，还在修改中。

第一个叫 apn 的程序是给 Mac OS X 中 Address Book 中的联系人自动生成姓名发音 (Phonetic Name) 的脚本，所以它的名字就是 Assign Phonetic Name 的缩写。

这是一个 Python 写的程序，直接用到了 pyzh 项目提供的汉字拼音转换代码，通过 Scripting Bridge 提供的 API 来访问 Address Book，这样虽然相比直接调用 Objective-C 的 API 有点慢，但好处在于能充分利用 Python 语言的灵活性。

使用起来很简单，从 github 上把代码抓下来 (你可以 git clone git://github.com/jjgod/apn.git 或者下载一个打包的版本)，然后执行

$ python AssignPhoneticName.py

就会自动给你 Address Book 中没有分配过 Phonetic Name 的那些联系人分配一遍。注意因为汉字有多音字，这个程序做不到很智能，你最好在分配之后打开 Address Book 校对一遍。

第二个是给 Cocoa 程序员用的一个 NSView 的子类，叫 PYView，其作用很简单，就是在汉字上方同步的显示拼音，不过目前拼音还得自己提供。

调用的 API 很简单，比如这样:

#include "PYView.h"

NSRect viewRect = NSMakeRect(50, 250, 700, 80);
view = [[PYView alloc] initWithFrame: viewRect
                            fontName: @”FZKai-Z03″
                               color: [NSColor whiteColor]];

NSArray *pinyin1 = [NSArray arrayWithObjects: @"nǐ", @"hǎo", nil];
NSArray *pinyin2 = [NSArray arrayWithObjects: @"zhōng", @"huá",
                    @"rén", @"mín", @"gòng", @"hé", @"guó", nil];


[view appendMarkerItem: [PYMarkerItem itemWithHanzi: @"你好"
                                             pinyin: pinyin1
                                               type: 1]];
[view appendMarkerItem: [PYMarkerItem itemWithHanzi: @"中华人民共和国"
                                             pinyin: pinyin2
                                               type: 1]];

就能得到如图所示的输出结果:

PinyinView

可以从 github 上获取代码:

 git clone git://github.com/jjgod/pinyinview.git

然后参考提供的 PYViewTest 代码来使用。注意接口还在修改中。

Adium 一些工作与开源软件相关的思考

更新: 原来 MSN 群中使用 /showname 命令也可以控制这一点。

另外 Adium 其实是个非常好的开发群体，非常 active & helpful，只是项目庞大到了这样，bug tracker 里的 ticket 一多，开发者自己也很难保证代码结构足够好了。

因为最近开始使用 MSN 群 (1, 2)，但我使用的 MSN 客户端 Adium 并不能将群内发言人的身份显示出来，只能全部统一显示为群本身的名称。

其实这是 Adium 所使用的 IM 协议支持库 libpurple 在支持 MSN 协议上固有的缺陷 — 不过也不算特别严重的缺陷，因为 Windows 版本的 MSN 也只在 Windows Live Messenger 8 以上才支持，而 Mac OS X 下的 Microsoft Messenger 干脆到现在也不支持。

所以，要修复这个问题，必须从 libpurple 上打主意，然而，因为 libpurple 编译不便 (后面我会解释为什么这么说)，Adium 本身的代码仓库中只提供了编译好的 libpurple framework，编译这个 framework 的步骤则是分离出来的，要单独用 Utilities/dep-build-scripts 下面的脚本来完成。

可是问题变得越来越 tricky 了：为了编译 libpurple 的代码，必须下载整个 pidgin 的代码，但 pidgin 的代码又是用臭名卓著的 Monotone 来管理的，这直接导致下载当前代码的步骤就变得复杂无比，更不用说后面的编译了。

这还没有完，崩溃的是，Adium 虽然其他协议的支持都是直接从 libpurple 来的，但偏偏 MSN 协议最近改用了从 libpurple 中 fork 出来的 msn-pecan 项目，而 msn-pecan 又是用 git 来管理代码的……

这么一来，为了修改 MSN 协议支持并编译出 Adium，我们必须至少涉及三套版本管理系统 (Subversion, Monotone 和 git)，把 Adium 提供的一堆错综复杂的脚本找出来，让它先给 libpurple 打上 Adium 自己的 patch，然后分 ARCH 来生成 configure 并分别配置编译，最后合并成 Universal Binary 再 copy 回 Adium 的 Frameworks 目录去… 到这里我还没开始改一行代码呢！

虽然这个问题最终得到了解决，我提交的 patch 也将合并到 msn-pecan 官方的代码中去，可是这个经历仍然让我觉得颇有体会：

从 F/OSS 项目的贡献者来讲，要成功的参与项目，就必须掌握好常用的版本管理工具并了解基本的编译手段，才有机会参与到真正的代码修改中去。

而从 F/OSS 项目的发起和维护者来讲，要创造一个成功的项目，应该：

  1. 避免使用怪异的版本管理工具
  2. 编译步骤简单再简单，尽可能分解为可以单独执行调试的步骤，尽可能减少会在编译时出现的问题