使用Portland改善Linux桌面移植性

乍看之下，Portland 的目标很普通。它只是用一致的方式包装了现有的功能 —— 图标的安装、屏幕保护程序的管理，所以开发人员不必为每个新的应用程序或要使用的桌面环境重新创建所有基本内容。而且实现该目标的代价非常小： Portland 的开源许可使得使用 Portland 无需金钱上的开支，其简单性实现了只花费很少的时间就可下载、安装和使用 Portland。结论很明显：很小的投资就得到了确切而显著的回报。所以这是个很容易做出的选择。

光辉的前景

如果相信 Portland 从现在开始还会继续发展下去，那么就很容易做出选择了。对于初始发行版，多数工作放在了基于 Linux 的 Gnome 和 KDE，而且 Xfce 也得到了 Waldo Bastian 所称的 “极大关注”，Waldo Bastian 是 Intel 公司 Linux 客户机架构师，一名主要的 Portland 贡献者。当 Portland 获得其首次成功应用之后，很自然会预测到它会扩展到更多桌面环境，甚至扩展到其他操作系统，例如 Solaris 或 FreeBSD。它的命令行实现当然可以让它扩展到新领域。从开发经理的角度来看，我很高兴为 Portland 界面编写代码。如果我的客户需要移植到 Portland 还不支持的桌面环境，对我们来说，实现一个正确的 Portland 扩展不会比把我们自己的代码应用到不支持的桌面环境上更难。

而且情况应当只会随着时间而改善。如果当前实现像我期待的那样流行，那么厂商，包括发行打包商，都会有兴趣维护和更新 Portland，尤其会使用特定于操作系统的方式来适应它们。同时，Portland 团队保证不会修改编程接口。Intel 的 Tom Whipple 准备的测试套件应当有助于保证这种稳定性。

围绕 Portland 有几个公开的问题。打包标准这个问题仍然需要协商。Portland 的设计者们很明智地对他们的架构设计进行最大程度地解耦；目前来说，打包问题已经被隔离，甚至还不知道最终的解决方案会是否是 Portland、Linux Standard Base（LSB）或其他工作的一部分。目前，Portland 仍只局限在编程访问典型窗口管理器的图标和其他组件。一旦发布了 KDE 4，编程接口可能会扩展到包含图标命名和共享的 MIME 数据库规范。

请记住，如果愿意，可以用称为 DAPI 的 C 绑定进行窗口管理器级别的进程间访问。尽管 XdgUtils 更加成熟，还可以从项目的 CVS 库中获得 DAPI 的早期发行版：

cvs -d :pserver:anoncvs@cvs.freedesktop.org:/cvs/portland \
co portland/dapi

有效的 DAPI 编码可以是模块化的，也可以是面向事件的。面向事件的情况下，应用程序连接到 DAPI，然后用 select() 方法侦听活动。模块化调用的示例是清单 2 中打开资源的函数（对发行版文档中的函数稍微做了修改）。

清单 2. 打开 URL 的 DAPI C 代码示例

/* Initialize with dapi_connectAndInit(). */ static DapiConnection* my_dapi_connection; int openURL(const char *url) { /* DAPI wants to know about toplevel_widget so it can properly handle focus, layering, ... */ if (dapi_OpenUrl_window(my_dapi_connection, url, XWINDOW_HANDLE(toplevel_widget))) return 1; /* Handle failure here ... */ }

结束语

如果应用程序，特别是应用程序的安装程序，直接处理桌面环境，那么 Portland 能提供一种实现相同功能的更好途径。只要对源代码做最少的修改，以及最少的许可影响或最少的编程困难，并且不会牺牲任何功能，就能够使用 Portland，获得多于自己所能数倍的移植性。而且从此还能利用未来 Portland 具备的任何增强和扩展。

原文链接：http://www.ibm.com/developerworks/cn/linux/l-portland.html