KDE4 for OS X 会受到用户欢迎吗?

KDE4 的[第一个 alpha 版本](http://www.kdecn.org/announcements/announce-4.0-alpha1.php)发布了,我们可以找到 for OS X 的[二进制文件下载](http://ranger.users.finkproject.org/kde/index.php/Home)。有个问题早在 KDE 社群宣布 native 的 OS X 移植时就被提起,我现在才有空瞎说点看法。

Mac OS X 的用户可能是世界上对软件的界面一致性 (consistency) 要求最高的用户,也许是因为选择 Mac 并热爱 Mac 的人的审美喜好也类似,所以他们的嗅觉也惊人的一致而灵敏,对软件的移植而言,他们能热切地赞扬优秀的 port,比如 [Skype](http://www.skype.com/download/skype/macosx),同样也有大量移植软件因为距离 OS X 用户的界面要求太远而不被关注。常见的跨平台 GUI Toolkit: GTK+, Qt 和 wxWidgets 都是如此,除非软件本身缺少替代品,比如 WireShark 和 [aMule](http://www.amule.org/),用户才会勉强接受它。

与 Windows 开发者喜欢创造千奇百怪的界面 skin 不同,也与 Linux 开发者干脆懒得认真开发界面不同,OS X 的开发者的倾向是紧跟 Apple 的步伐。Apple 放弃 [Brushed Metal](http://indiehig.com/wiki/UI_Elements_to_Avoid) 风格,他们也立即放弃,Apple 在 Mail 里用 [Unified Aqua](http://indiehig.com/wiki/Unified_Aqua) 工具栏,他们也赶紧用,Apple 在 iLife 和 iTunes 里开始用 [Polished Metal](http://indiehig.com/wiki/Polished_Metal) 和 [HUD 窗口](http://indiehig.com/wiki/HUD),并放弃 Drawer,他们也一一复制,造就的结果就是用户口味特别刁钻,稍有点异味都能品出来,比如 Shiira 的开发者最近伴随 2.0 版本的发布提供了 [HUD Framework](http://shiira.jp/hmblkappkit/en.html),但却[有人声称](http://dev.lipidity.com/apple/shiira-2-released-offers-hud-framework) CSSEdit 的 HUD 窗口“ blow these away by a mile”——就是这么苛刻,不过,如果你也是个对 GUI 设计精益求精的开发者,你就能习惯它。

大多数的跨平台 GUI Toolkit 最大的问题在于,它们能达到的只能是所有平台支持的“最大公约数”,而永远无法在任意一个平台下发挥最大效能,所以它们只好设置自己的 Design Guidelines,为了让不同平台下都呈现相同的外观和习惯。它们可能去为了 [Apple Human Interface Guidelines](http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGIntro/chapter_1_section_1.html) 乃至 [indieHIG](http://indiehig.com/wiki/Main_Page) 去修改自己的界面设计习惯吗?恐怕很难。

而且 KDE 的习惯又是以复制 Windows 为主,包括 File Choose Dialog 的设计,OK, Cancel Button 的位置,等等,从而就更难让 OS X 用户满意了。

事实上,跨平台的 GUI Framework 从来就没有达到过真正的跨平台的接受度,一般都只能在一个平台下拥有大量用户,其他平台下则寥寥无几。我觉得还是在软件内部封装一个跨平台 GUI 层,根据不同的需求在不同平台下调用不同的框架来实现会比较好,比如 vim 和 emacs 的做法就是如此。

管理大型的 Cocoa 项目

NetNewsWire 的作者 Brent Simmons 最近的一篇文章介绍了[如何有效的管理大型 Cocoa 项目](http://inessential.com/2007/04/25.php)。他的建议可以总结为下面几条:

为了改善代码的可读,可查找性,应该遵循:

1. 只对那些没有明显关系的对象之间的交互使用 Notification。
2. Key-Value Observing 也是很危险的,应该只对 Preferences 项目使用这一特性。
3. 只将 Binding 用于很简单的情形,复杂的 TableView 还是用 datasource/delegate 比较好。

管理代码时可以使用的技巧:

1. 用 `#pragma mark` 来划分代码的区域
2. 用 Ctrl-2 来列出当前打开文件的符号 outline。
3. 用 Shift-cmd-D 来快速打开指定文件。
4. 用 opt-cmd-T 来将当前打开的文件和左侧的目录树同步。
5. ctrl+double click 打开符号的定义,opt+double click 打开符号的文档。
6. 在文件系统中用平面方式组织文件,不划分多层目录,在 Xcode project 中用 group 来划分层级结构。

对于有 Cocoa 开发经验的人,尤其是管理过这种超过 200 个源文件的较大项目的人来说,这些经验是很有用的。