最终用户只关心能够执行所需任务的应用程序。他们来到 Linux 是为了能够自由地逐个选择这些应用程序。对他们来说，集成的桌面意味着自由选择任何程序组合，并确保它们协同工作。单片桌面环境也可能限制程序员。确保您的代码与现有应用程序协同工作对于好的软件至关重要，如果不是使其有用的主要特征。为了实现这一结果而被迫使用一两个开发工具链就显得毫无意义了。

GNU/Linux 桌面的一个痛点曾经是 XFree86——开发进展太慢，性能不令人满意。许多工具，从 fontconfig 到 zlib，都被重复开发以避免外部依赖。如果一个驱动程序发生更改，整个软件包都必须重新发布。最重要的是，XFree86 许可证在去年更改为一个似乎禁止 GPL 程序链接到任何新代码的许可证。一些发行版立即做出反应，没有发布带有许可证问题的新版本。

Freedesktop.org (FD.o) 于 2000 年 3 月成立，旨在帮助开发人员解决上述技术问题。该项目的目标是创建一个基础平台，每个桌面都可以在其上构建。方法是定义独立的规范，并在需要时完成工作代码。正式标准化留给其他机构。遵循这些规范应尽早保证应用程序之间的真正互操作性，最好是在开发开始之前。所有软件都将置于 LGPL 或 X 风格的许可证下。FD.o 托管了许多优秀的项目，但本文介绍了构成所谓 FD.o 平台的主要工具。

图 1. Freedesktop.org 的集成方式：所有应用程序都可以使用的服务器、库和通信协议，无论它们诞生于哪个桌面环境。

X Window 系统是一种用于图形显示的网络透明协议。GUI 程序使用 X 向称为 X 服务器的软件发出绘图命令，X 服务器实际上控制屏幕。直到去年，服务器和库通常都包含在单片软件包中。然而，FD.o 将该捆绑包分解为多个部分，现在可以分别开发和打包。这的主要优点是程序员和 Linux 发行版可以随意混合和自定义每个部分的各种实现。

其他 X 改进包括删除所有树内依赖项，使用 autotools 作为构建系统，以及使用 iconv 库进行 Unicode 和其他编码之间的所有转换。包装 X 协议的库称为 Xlibs。FD.o 于 2004 年 1 月发布了它们的第一个版本。它们符合 X 标准，因此可以与任何 X 服务器一起使用。

即使经过多次优化，Xlibs 的大小也可能在低端平台上造成问题。此外，即使不是真的必要，一些 Xlibs 请求也会阻塞，直到收到回复。这可能会干扰 2.6 内核中的一些延迟降低功能。Xlibs 还通过缓存、分层和类似的努力做了很多工作来隐藏协议；这些努力在许多情况下是一种优势，而在另一些情况下则是一种开销。最后但并非最不重要的一点是，对创建 X 扩展的支持有限。

FD.o 解决这些问题的方案是 X C Binding，简称 XCB。第二个库可以作为新工具包和 Xlibs API 部分的轻量级仿真的基础。XCB 旨在与 POSIX 线程或单线程程序透明地工作。该代码保持与 Xlibs 扩展和应用程序的二进制兼容性，并且可能不需要重新编译扩展。这使得从 Xlibs 到 XCB 的缓慢、逐步迁移更容易，而不会丢失功能。沿着这条道路的下一步，Xlibs 兼容层 (XCL)，应该允许构建在 Xlibs 之上的现有应用程序利用 XCB。

FD.o 托管了 XFree86 的两个替代方案。第一个方案是在许可证更改之前，作为 XFree86 4.4-RC2 代码的分支开始的。此服务器称为 X.org，其使用方式与 XFree86 相同。另一个替代方案称为 Xserver，从长远来看是最有希望的选择。它是 Kdrive 的分支，Kdrive 多年前作为 XFree86 的轻量级、高度修改的版本开始的。Kdrive 体积小，部分原因是它与内核的代码重复较少。尺寸减小也是通过删除一些过时的功能和驱动程序模块来实现的。更小的代码尺寸使得从 Kdrive 开始构建全新的服务器更容易。

今天可用的 Xserver 版本仍然主要用作新扩展和功能（例如透明度或 OpenGL 加速）的测试平台。通过在运行时执行大量计算而不是始终将结果保存在内存中，最大限度地减少了内存使用量。

Xserver 的目标是减少缓慢以及其他使观看屏幕不愉快的现象，包括闪烁。一个新的 X 扩展，称为 Composite，允许对整个屏幕进行双缓冲。当然，没有服务器可以比其最愚蠢的客户端更智能，但更轻量级的架构应该更容易找到和修复缓慢的代码，无论它在哪里。新的服务器在工具包级别没有影响，除非程序员选择直接利用新的扩展。

矢量图形通过绘制或多或少复杂的线条并用颜色填充结果区域来创建图像。相应的文件尺寸小，并且可以以任何分辨率缩放而不会造成损失。因此，这种技术对于每个想要确保他们打印的内容与他们看到的内容一致的人都很有意义。不幸的是，X 知道如何管理文本、矩形等的屏幕像素图，但它只是忽略打印或矢量图形。这是我们仍然无法在屏幕、纸张和保存的文件之间实现 100% 一致性的原因之一。

FD.o 的解决方案是 Cairo，“一个具有跨设备输出支持的新型 2D 矢量图形库”。用通俗的英语来说，这意味着在所有输出介质上结果都是相同的。在外部，Cairo 提供类似于 PDF 1.4 图像模型的用户级 API。

通过不同的后端，Cairo 可以支持不同的输出设备。第一个是屏幕，通过 Xlibs 或 XCB，以及内存中的图像缓冲区，然后可以将其保存到文件或传递给其他应用程序。已经可以进行 PostScript 和 PNG 输出，并且计划支持 PDF。OpenGL 加速输出也将通过一个名为 Glitz 的后端提供。此外，可以使用 Glitz 作为 OpenGL 之上的独立层。Cairo 语言绑定存在于 C++、Java、Python、Ruby 和 GTK+ 中。

OpenOffice.org 的开发人员也计划在 OOo 套件 2.0 版发布后使用 Cairo，甚至可能作为单独下载的图形插件。Cairo 仍处于积极开发中，并且缺少完全稳定的 API，因此尚未包含在官方 FD.o 平台版本中。

D-BUS 是一种用于在一个桌面会话的应用程序之间或该会话与操作系统之间进行进程间通信 (IPC) 的二进制协议。第二种情况对应于每当向计算机添加新硬件或软件时与用户的动态交互。Robert Love 在 2005 年 2 月的《Linux Journal》杂志的“Get on the D-BUS”一文中讨论了 D-BUS 的内部结构。就桌面最终用户而言，D-BUS 至少应提供与当前 GNOME 和 KDE 中可用的服务相同级别的服务。为了实现这一点，系统守护程序（称为消息总线）和每个用户、每个会话的守护程序都可用。两个程序也可以通过使用 D-BUS 直接通信，以最大限度地提高性能。出于同样的原因，由于使用相同 D-BUS 的程序几乎总是位于同一主机内，因此使用二进制格式而不是纯 XML。

消息总线守护程序是一个充当路由器的可执行文件。通过在应用程序之间传递消息而不是字节流，守护程序使其服务可用于桌面。通常，每台计算机上都有多个独立的此守护程序实例。一个将用于系统级通信，对其可以接受的消息有严格的安全限制。其他实例将为每个用户会话创建，以服务于其中的应用程序。系统范围的 D-BUS 可能会成为安全漏洞：以 root 身份运行的服务必须能够与用户应用程序交换信息和事件。因此，它的设计具有有限的权限，并在 chroot jail 中运行。D-BUS 特定的安全指南可以在 Fd.o 网站上找到（请参阅在线资源）。

大多数程序员不需要直接与 D-BUS 协议对话。有包装器库可以在任何所需的框架或语言中使用它。这样，每个人都能够维护自己喜欢的环境，而不是专门为了 IPC 而学习或切换到新的环境。最终用户再次在互操作性方面获得收益：KDE、GNOME 和 Mono 程序将能够相互通信，而与工具包无关。与 Cairo 一样，FD.o 平台的第一个版本不包括 D-BUS，因为其 API 尚未稳定。但是，开发人员认为 D-BUS 是未来版本的基石。D-BUS 也旨在取代 KDE 4 中的 DCOP。

只有时间才能证明 Fd.o 的第一个实现是否足够好，以及相关规范是否有效。在这种情况下，有效意味着完整的东西，如果有人愿意这样做，可以从头开始用全新的代码重新实现。但我确信，这种方法是有效的，并且比任何其他现有的“完整桌面”都更具潜力。

到目前为止，我读到的两个最常见的抱怨是：1) 当前的桌面将失去其身份，变成“仅仅是用户界面”，以及 2) FD.o 不是标准，仅仅是其他实现。我对第一个担忧的个人回应是，即使它发生了，这真的是一个问题吗？大多数最终用户甚至不会意识到这一点，也不会为此感到担忧。他们很可能会注意到我在开头提到的改进，然后就此作罢。确保所有应用程序都可以协同工作，无论它们是如何开发的，也将使 Linux 更容易被企业桌面接受，从而堵住一类支持专有解决方案的论点。

如果协议和格式不再与特定的实现或工具包绑定，它们就可以在多个“桌面环境”之间共享。代码稳定性和轻量级将直接从中受益，创新也将如此。全新的程序可以立即与现有程序交互。因此，我希望这种趋势能够普及，并且更多与应用程序无关的标准提交给 FD.o，涵盖文件格式、声音方案、颜色和任务设置。想象一下，一个邮件配置文件可以被从 Evolution 到 mutt 的任何电子邮件客户端使用，或者一个书签文件可以被从 Mozilla 到 Lynx 的每个浏览器使用。

至于第二个反对意见——FD.o 不是标准，仅仅是其他实现——这正是自由软件和 RFC 的工作方式。只要规范与代码一起编写，概念就可以尽快在实践中得到验证。记录在案的是，同样的事情目前正在 OO.o 和 OASIS Office 标准中发生（参见LJ，2004 年 4 月）。文件格式在 StarOffice 和 OO.o 内部开始并成熟，但现在它有了自己的生命。该委员会目前包括来自 KOffice 的代表，并且任何未来的办公套件都可以将其用作其本机格式，仅从规范开始。

这条道路上确实存在一些陷阱，但据我所知，开发人员意识到了这些陷阱，并决心避免它们。第一个风险是开发出的标准出于某种原因仅在 Linux 上运行良好，而忽略了其他 UNIX 系统。另一个是资源使用：如果运行顺畅需要将 RAM 翻倍，那么这里描述的所有魔法看起来都会逊色很多。然而，就我们今天所知，这似乎是不太可能的。无论如何，现在是加入这项工作的最佳时机。祝您 hacking 愉快！

非常感谢 Waldo Bastian、Keith Packard、Daniel Stone 和 Sander Vesik 的所有解释。

本文的资源： /article/8135。