至还不知道最终的解决方案会是否是 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