在构建桌面 Linux 应用程序的开发计划时，可能需要适当考虑到底针对哪个桌面 环境（DE）进行开发。Gnome 还是 KDE？当然可能还有其他的桌面。

但是如果只考虑一种桌面环境，那么应用程序的销售可能不会长久，以 Portland 项目 为例。

Portland 项目

首先介绍一些背景知识。Portland 项目是为了解决一些恼人的问题，这些问题将在软件开发人员编写易于移植到所有 Linux 发行包中打包的各种桌面环境（DE）时制造麻烦。具体来说，Portland 的目标是提供一套开发人员可编写的通用 API，从而使应用程序无需考虑桌面环境。

该项目第一个也是目前实现的阶段 Portland 1.0，名为 XdgUtils，它是一些实用程序的捆绑，应用程序可以用它在现有的桌面环境上运行。第二个阶段 Portland 2.0 的计划包含基于 D-Bus 接口的面向服务的进程间通信机制。

虽然 XFCE、GNUStep 和 MacOS X 也在未来的考虑之中，但 Portland 目前只支持 KDE 和 Gnome。

在本文中，将开始使用 Portland 的 XdgUtils 部分，还将了解 Portland 的设计如何反映其更广泛的目标。

请看清单 1，它显示了 xdg-email 实用程序的用法：

清单 1. xdg-email 的示例用法

# This invocation is valid for all desktop
# environments and any e-mail client a user
# may prefer.
xdg-email --cc $COLLEAGUE --bcc $SELF 
   --subject "Problem report" 
   --body "This is a semi-automated fault report.  You
          can edit this e-mail before sending it.
          Note that the problem log is automatically
          attached." 
   --attach $LOG errors@$OUR_HOME

看到其中发生的变化了吗？这一个命令就替代了为适应诸如 Firefox、elm、/bin/mail、Opera 等等众多电子邮件客户机而需要实现的数页脚本。

为了更容易理解和全面应用这类命令，这里介绍一些背景：桌面环境包含 窗口管理器、图标、工具栏、应用程序、墙纸、功能（包括拖放）和构成桌面计算机用户即时体验的独特外观和感受。常见的桌面环境有 Gnome、KDE、XPde、ALDE、Xfce 及其他。您希望您的程序在自己和客户或同事使用的桌面环境上看起来很 “自然”，而且运作良好：剪切和粘贴应当立即发生，颜色调色板不会损坏客户的屏幕，应用程序的正确安装应当显示在桌面应用程序选择菜单中合理的位置。

一直到最近，实现这些目标的可靠方式还是使用和熟悉特定桌面环境的规范 —— 例如 KDE —— 然后请教专家或者重新学习每一种其他桌面环境要求的规范。在这个级别上，重点很少是实现特殊的功能或者用复杂的方式移植应用程序；原则上讲，正确安装的 Linux 应用程序应该能用任何桌面环境的窗口管理器显示。只有安装中更精细的细则，包括必要的库的位置以及一些较小的图形修饰，才会区别不同的桌面环境。

但是，如果不只是为自己和少数程序员开发应用程序，而是要开发广泛发行的商业产品，那么正确了解这些细节是必需的。请注意，我没有研究最终用户将看到的生动的显示效果：Portland 并不解决 GUI 主题的 “花俏”，或者阴影效果又或者虚拟文件系统创新。Portland 只是帮助开发人员的代码在进行安装和部署自动 化时，呈现更合理的界面。

清单 1 显示了一个典型的现实示例，给出了一个最终用户能够在其所选的电子邮件客户机中编写的电子邮件消息。Portland 定义了 xdg-email 命令，它管理这类任务中包含的所有常见套路。调用这样的命令行会启动用户的电子邮件客户机，填充它的元素（例如列表、附件等），并把控制权转移给最终用户。应用程序需要这种帮助吗？如果需要，那么 Portland 正是为您准备的。

Portland 初探

去年，Portland 实用程序才开始面向公众，但是不要沮丧：这个项目正在不断地实现它的目标，即使是现有的版本，也非常有用。不过它仍然缺少详细的教程和其他的一些标准规范。

要开始使用 Portland，请用匿名 CVS 获得源代码：

cvs -d :pserver:anoncvs@cvs.freedesktop.org:/cvs/portland
co portland/xdg-utils

这样就下载了一组命令行工作 XdgUtils，还有初步测试计划、 测试套件的开头部分、基本的安装程序、HTML 化的手册和少量管理文件。文档和其他优化最后会包含在其中。 Portland 还集合了称为 桌面 API （DAPI）的 C 绑定。 下一节将会看到 DAPI。

XdgUtils 包含的工具能够完成下面的功能：

• 安装和卸载桌面图标、图标资源和菜单项
• 使用用户喜欢的编辑器或邮件用户代理编写电子邮件
• 查询和管理文件类型（.gif、.c 等）和它们的描述
• 使用用户选择的合适的应用程序打开文件或 URL（如 Windows® 的 start 命令行或 Mac OS X 的 open）
• 控制屏幕保护程序
• 使用一致和安全的方式增加程序权限

使用任何语言或开发环境的开发人员应当都能访问这些工具；可以使用编程方式调用它们，如同使用 shell 中的其他命令一样。例如，如果正在使用 Python，那么可以在 bash 代码编写的安装脚本中使用 XdgUtils 工具，也可以使用系统调用，就像下面这样：

os.system("xdg-open %s" % chosen_URL)

或者，也可以使用 Python 的任何其他函数更精细地控制外部进程。

乍看之下，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 具备的任何增强和扩展。