GTK+ 基础，第 3 部分: 如何部署 GTK+

Maciej Katafiasz ( ibmdw@mathrick.org), 学生, 计算机科学
“ GTK+ 基础” 系列的前两篇文章介绍了 GTK+ 是什么以及可以用它来做什么。本文是这个系列的最后一篇文章，将介绍把产品提供给用户所需的一切 —— 即学习如何部署 GTK+ 应用程序。

独一无二通常是件好事，但在库函数中却并非如此。对于软件来说，越流行就意味着评论越多，所报告的 bug 也越多（因此修正的 bug 也越多），也就有更多的机会可以测试到各种不同的案例和不常见的情况。所有这些通常都将导致更好、更容易地使用库函数。幸运的是，GTK+ 扮演了一个重要的角色，它是使用最为广泛的软件包之一。注意下面这些有关运行 GTK+ 的不同平台的信息：

UNIX®

UNIX 是最初开发 GTK+ 时所使用的平台，GTK+（与其竞争对手 Qt 工具包一起）已经成为一个实际的 UNIX 标准。目前已经开发了数千个 GTK+ 应用程序，它们都可以在 UNIX（以及类 UNIX）系统上运行。除了单独的应用程序之外，GTK+ 还可以在另外两个桌面环境（GNOME 和 XFce）上运行，其目标是提供完整的用户体验。如此丰富的资源使它成为了一个可自我持续发展的生态系统，其中开发的每个项目都是在新获得功能的基础上进行的。早期开发的很多东西后来都融入到 GTK+ 中，例如， libgnomeui 中相当大的部分现在都可以在 libgnomeui 中找到。

Microsoft® Windows®

Win32 移植后来被加入到运行 GTK+ 的平台中，但是现在 Win32 现在已经成为一个重要组件。大部分小型和中型的 GTK+ 应用程序都可以在 Win32 系统上进行编译和运行（当然，它们并不能执行 UNIX 特有的一些基本操作），更大的应用程序也可以成功移植。最初的 GNU Image Manipulation Program (GIMP) 就是最好的一个例子（也是最早的一个例子），但是这种例子远远不止这一个。例如，优秀的 Gnumeric 制表软件从 V1.4 版本开始发行了一个正式的 Windows 移植版本。

Mac OS X

Apple 的最新操作系统实质上就是一个 UNIX under the hood，因此让 GTK+ 在这上面正常工作并不太难。实际上，有些应用程序（如 GIMP）已经对 Mac OS X 进行了特殊的修改，以便更适合 Mac OS X 特有的用户界面 (UI) 习惯。

应用程序产品线

不管您是否喜欢，软件开发并不仅仅是非常愉快地编写一行行的代码。要开发一个成功的产品，首先需要创建一个让开发人员可以进行开发的产品线。

程序员

当然，这个产品线中最重要的部分就是程序员。如果某个库非常难使用，或者有一些非常奇怪的需求，又或者很难与其他组件进行集成，那么这个库可能不是很适合您的产品。幸运的是，GTK+ 没有这些问题。GTK+ 的应用程序接口 (API) 是一致的（如果不考虑偶然会碰到的无法向后兼容的情况），它们本身设计得非常容易使用和记忆。但是我们在使用时仍然需要谨慎，尽量避免出现与其他库冲突的情况：每个 API 都有自己适当的名称空间（使用了给定编程语言中提供的机制），导出符号的数量要保持最小化，这样在链接时才可以使这个库更安全，速度更快。

编译系统

pkg-config 命令 pkg-config 命令因为其零启发式 (zero-heuristics) 方法而非常出名。这种方法与 UNIX 系统上用来寻找库的传统方法不同，它会使用为特定任务精心定制的脚本（不过不幸的是，这也很容易产生错误）。相比之下，GTK+ 采用了另一种不同的方法：它使用了一个精心定制的脚本 gtk-config（以及 glib- 和 gnome-config）。对于 V2.0 版本来说，这个方法是经过整理的，并被扩展为一种通用解决方案 pkg-config，它遵守 freedesktop 项目所制定的规范。这种新解决方案非常不错，现在已经成为用来寻找库的实际标准。有了这些详细的规范，就很少有机会出错了。

由于编译程序是在开发过程中需要无数次重复做的事情，因此我们自然就会希望使用一个自动化的编译系统，把自己从手工编译程序的繁杂事务中解放出来。由于编译系统必须解决所有编译软件问题，因此我们需要确保各个部分可以很好地集成在一起工作。在这里，GTK+ 就是非常好的一个例子。它有一个单一的集成点，即 pkg-config 命令。这个命令让您可以检查 GTK+ 是否存在，版本是否正确；还可以对长长的选项行进行分割，这样编译器就可以找到自己的库了。

GTK+ 自己并没有任何特殊的需求，使用它时只需要包含一个头文件即可。它既不需要涉及预处理器和特殊的编译器，也不会产生其他重大的负面影响。

GTK+ 本身使用了 GNU Autotools，后者包含适用于 Autoconf 和 Automake 的一些现成的宏（为 GNOME 项目编写的），这些宏使我们可以只通过一个调用来检测并正确配置 GTK+。不过即使使用不同的编译系统，也可以很容易地将 GTK+ 集成到这个系统中。我们只需要一个定义良好的 pkg-config 调用即可。否则，如果正在使用基于目录的系统（例如 Microsoft Visual Studio），那么只需要在编译路径中简单地包括几个目录即可。

发行完成的应用程序

将最终的产品发送给用户使用是一项与平台密切相关的任务，因此如何将应用程序与 GTK+ 进行集成在很多平台上都会有所不同。对于 UNIX 平台（尤其是 Linux®）而言，可以认为 GTK+ 是操作系统供应商提供的一个系统库。如果您不希望这样，可以使用另外一个解决方案：Autopackage 项目（请参阅 参考资料），该解决方案允许您创建将自动安装所需要的库的包。

在 Windows 上存在很多安装系统。例如，标准的 Windows InstallShield 和 Nullsoft 的 NSIS 都被广泛用来提供各种软件，其中包括 GTK+ 本身。这些库的所有二进制发行版本都使用了标准的注册表关键字和配置数据，这样，多个应用程序就可以使用相同的共享副本，并且允许我们使用其他安装系统对自己的应用程序进行安全打包。

跨平台可用性

根据目标系统的不同，可用性（以及我们对部署的期待）也会有所不同：

• 对于某一个 Linux 发行版而言，我们可以合理地假设 GTK+ 可以通过常见的发行手段来使用。大部分发行版本都可以快速集成 GTK+ 发行版本，我们可以期望在最新的发行版本中，至少有 2 个最新的版本可以使用。然而，由于无法保证所有的用户使用的都是最新的 Linux 版本，因此在开发应用程序时，我们的一个目标是让程序能够在可能最早的 Linux 版本上运行。
• 在运行 Windows 的计算机上，GTK+ 只是一个第三方组件。然而，有了不同安装包所提供的统一布局的帮助，如果系统中已经安装了 GTK+，那么我们可以安全地依赖于这个版本；否则可以自己安装 GTK+。由于 GTK+ 运行时的安装也都包含在了安装过程之中，因此我们可以更加自由地选择要使用的版本，如有可能，请选择使用较低的版本。尽管 GTK+ 小组非常注意保持 GTK+ 的向后兼容性，但是要捕获所有的 bug 是不太可能的。通常，采用版本较低的库极大可能使应用程序的安装变得非常简单。
• 对于 Mac OS X 来说，GTK+ 完全是一个外部包 (foreign package)。为了更加安全，它提供了一个自包含的应用程序来帮助用户克服依赖性的问题。要想了解这种程序的例子，可以查看如何构建 Gimp.app（请参阅 参考资料）。

您应该会注意到 Mac OS X 上的 GTK+ 有两种风格。对于迄今为止发行的所有版本来说，必须通过 Apple 的 X11-to-OS X 桥来使用 GTK+。然而，在最新的开发版本中，增加了一个到 Mac OS X 窗口系统的新本地移植，这使得将来为 Mac OS X 移植提供集成级别有可能类似于目前为 Win32 移植提供集成级别。

我们还需要清楚地了解 GTK+ 中的应用程序二进制接口 (ABI) 兼容性到底意味着什么。虽然库的开发人员热衷于尽量保持 GTK+ 的向后兼容性，但是对于我们的程序来说，这只意味着应用程序也可以保持向后 兼容性 —— 也就是说，随着 GTK+ 的升级，这些程序依然可以正常工作。具体来说，假设我们的源代码只使用了 2.2 版本的 API，如果我们使用 V2.6 版本的系统进行了编译，那么生成的二进制程序也许不能 在使用 GTK+ V2.2 的系统上运行。这是因为在编译时会引用新版本中添加的 ABI，这在安装旧版本 GTK+ 的系统上会产生运行时错误。

让应用程序可以兼容 GTK+ 的以前版本（如 2.2）的一个方法是安装真正的 GTK+ V2.2 发行版，并使用这些头文件来编译我们的包。尽管事实证明这对于开发人员来说虽然不是最简单的方法，但却是惟一可靠的方法。

要解决这个问题还有其他一些方法，例如在编译时明确定义版本参数，从而可以在不同版本的头文件之间进行切换。例如，在 Windows 软件开发包 (SDK) 中就使用了这种技术。但是这种方法也有一些缺点，它生成的头文件会很难理解和维护，有时甚至会产生一些奇怪的效果。由于这个原因，GTK+ 的维护者决定不再支持这种编译方法。

如果正在使用的是 Linux 平台，那么可以从 Autopackage 项目主页上获得预先打包好的早期版本的 GTK+ 头文件，同时还可以获得一些用来简化可广泛发行版本的二进制文件生成过程的工具。有关的更多信息，请参阅 参考资料。

回页首

根据自己的需求对 GTK+ 进行定制

通常，我们对 GTK+ 默认情况下提供的功能可能并不满意。原因有两个方面：我们可能希望使用基本库没有提供的一些功能，或者我们可能希望对这个库进行一些修改，从而能够更好地符合我们的要求。

第一种情况非常简单。我们需要寻找一个外部的库来提供所需的功能。我们可以从几个地方开始寻找这种库的提供者。通常，与我们类似的需求可能早已经在一个很大的项目（例如 GNOME）中提出来过。由于这个原因，GNOME 维护了几个模块，它们可以作为某些有趣特性的沙盒使用；虽然这些特性还不够成熟，尚不能集成到 GTK+ 中，但是它们的确非常有用，并且可以实现很多功能。在 GNOME CVS 中，这种模块中最出名的一个叫做 libegg。您可以在很多提供这个模块的站点上找到它，例如 SourceForge.net 和 freshmeat（请参阅参考资料）。

当我们希望修改 GTK+ 本身的一些内容时，就会出现第二种情况。例如，我们可能希望在某些嵌入式体系结构上运行 GTK+，或添加一些对特殊交互类型的支持。根据我们的需要（或功能要求），可以选择几种可用的方法。

最简单的方法是在邮件列表上发一条消息，询问一下是否有人已经实现了我们想要的功能。如果我们进行的修改是大家普遍感兴趣的，而且质量也足够好，那么它们很可能被集成到 GTK+ 的主要发行版本中。

不过，如果我们的项目非常特殊，可以考虑雇佣一个专门的咨询公司帮助我们与社区进行沟通，确定其中的关键点。Nokia 最近采用的就是这种方法，它们决定使用 GTK+ 作为个人手机设备产品线的基础。最终的结果是它们选用了 maemo 平台，这个平台在整个社区中获得了良好的声誉（实话实说）。仔细选择合作伙伴和方法可以让双方实现双赢：公司得到了很多经验丰富的程序员来开发新的产品，而社区则在开发过程中获得了很多改进和全新的用户案例，这可以极大地扩展 GTK+ 提供的应用范围。

回页首

GTK+ 社区

黑客和 GTK+？ 在 GTK+ 邮件列表和其他材料上，很多时候您都可以看到黑客 (hacker) 这个词。这并不意味着有人计划侵入您的系统，这只是普通大众对这个术语的一个常见感觉而已。实际上，黑客代表的是一些从事某方面工作并且对某种产品非常熟悉的人，这才是黑客一词的本意。这就是为什么在这个邮件列表的帖子中经常会看到 GTK+ hacker、GNOME hacker 以及类似的一些词语的原因。

当您踏上 GTK+ 的探险旅程时，它周围的社区就是您的一线支持资源。因此，了解应该从哪里入手非常关键。这些知识可以帮助您节省很多时间，还可以尽量减少不必要的误解。

与 GTK+ 有关的开发主要集中在三个邮件列表中：

gtk-list

此通用邮件列表负责解答所有与编程无关的 GTK+ 问题。例如，在这里可以询问有关许可证的问题。这也是惟一一个可以张贴提供工作信息的地方。

gtk-app-devel-list

此邮件列表关注的重点是 GTK+ 应用程序的实际开发工作。对于所有类型的编程问题来说，这应该是我们的默认选择。如果不清楚到哪儿去问问题，那么可以在这个邮件列表上提出来。

gtk-devel-list

此邮件列表专门提供给那些从事 GTK+ 本身（而不是应用程序）开发的开发人员使用。由于有效进行沟通对于今后版本的顺利开发而言非常重要，因此我们应该尽量避免在这个邮件列表上提一些无关的问题。例如，询问有关使用 GtkTreeView 的问题在这儿就不太合适。但是，如果您认为某一问题是一个 bug，或者是一个值得改进的地方，那么在这里提这种问题就非常合适 —— 实际上，这非常受欢迎。

GTK+ 开发人员都会定期阅读这三个邮件列表，因此我们不用担心自己的帖子会被忽略。

我们应该熟悉的另外一个站点是 Bugzilla，这是一个 GNOME bug 跟踪系统，同时还存放了 GTK+ 的 bug 数据库。任何时候您怀疑某些行为不正确时，都可以查阅 Bugzilla，了解这个问题是否早已报告过。我们也可以自己报告问题，使 GTK+ 可以变得更好。即使我们不太确信所发现的问题是否是一个 bug，但是只要能够提供充分的信息，就不用担心这个问题。最坏的情况就是这个 bug 被标记成 NOTABUG 而关闭了。

除了这些资源之外，还可以在很多 IRC (Internet Relay Chat) 频道上获得实时的支持，其主服务器是 GIMP.net。在频道 #gtk+ 和 #gnome 上，通常都会有人可以帮助您。但是要有点耐心，“通常” 并不意味着必须 “在 5 分钟之内”。

当您加入这个社区之后，就会发现这里有很多伟大的人物，即使只是呆在那儿也会非常有趣，您也许能在一些您熟悉的问题上为其他人提供帮助。记住，您不可能总是第一次碰到问题的人，所有的问题都会得到解决的。

回页首

对将来的展望

GTK+ 不断地为开发人员改进自身，每个新版本都提供了设计用来简化其使用的特性。由于这个原因，GTK+ 还实现了几个互操作标准，例如 freedesktop 项目定义的标准（请参阅 参考资料）。

不过，有一个非常出名的特殊项目被设计用来为独立软件供应商 (ISV) 提供辅助，让查找正确工具的过程变得更加简单。这个项目名为 Project Ridley，它集成了很多以前独立的库和插件，实现了一个简单易用的一致平台。例如，可以集成现在的很多 GNOME 库，在运行 GTK+ 的平台上利用这些库的优点。另外，在本系列文章的 第 2 部分 中介绍的 libglade 现在也已经计划包含到 GTK+ 平台中了。希望在 Project Ridley 完成之后，所生成的平台版本会变成 GTK+ V3.0（但是它依然与目前的 2.x 发行版兼容）。

回页首

结束语

本文是 “GTK+ 基础” 系列文章的最后一篇，在本文中，我们学习了很多用来开发成功的软件产品所需要的技巧。我们查看了在不同平台上如何支持 GTK+，怎样最好地交付 GTK+ 应用程序，以及如何对 GTK+ 进行定制，以便更好地满足我们的要求。最后，我们对将来的版本进行了展望，这样我们就具备了开展 GTK+ 旅程所需要的知识。

希望我们很快就可以见面 —— 可能是在邮件列表上，也可能是在一个 IRC 频道上。不管是什么情况，我都希望能够将您引入 GTK+ 的精彩世界中。

参考资料

学习

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• 请阅读 developerWorks “GTK+ 基础” 系列文章中的所有文章。
  
  
• GTK.org 是 GTK+ 项目的主页。
  
  
• GNOME Bugzilla 是针对 GNOME 和 GTK+ 使用的一个 bug 跟踪系统。
  
  
• freedesktop 是专门为开放源码桌面系统设计的一个交互操作能力项目。
  
  
• ProjectRidley 专用于将 GTK+ 开发成一种新级别的编程平台。
  
  
• 跟踪 developerWorks 技术事件和 Webcasts 的最新进展。
  
  
• 请访问 developerWorks 开放源码专区，从那里可以获得丰富的 how-to 信息、工具和项目更新，这些有助于您用开放源码技术进行开发并把它们用于 IBM 产品。
  
  

获得产品和技术

• 了解 autopackage，这是 Linux 使用的一个跨发行版的打包解决方案。
  
  
• 下载 Gimp.app，这是为使用 GTK+ 的 Mac OS X 提供的一个示例应用程序包。
  
  
• SourceForge 是一个免费的寄存场，也是很多 GTK+ 应用程序和库的家园。
  
  
• 请访问 freshmeat，这是为各种项目提供的一个仓库，其中很多项目都与 GTK+ 有关。
  
  
• 用 IBM 试用软件 改进您的下一个开发项目，可以通过下载或从 DVD 中获得该软件。
  
  

讨论

• 请访问 gtk-list，这是一个有关 GTK+ 的通用讨论列表。
  
  
• 还请访问 gtk-app-devel-list，这是为 GTK+ 应用程序提供的主要编程论坛。
  
  
• gtk-devel-list 讨论列表专门用来讨论 GTK+ 本身的开发。
  
  
• 通过参与 developerWorks blogs 加入 developerWorks 社区。
  

关于作者

		Maciej Katafiasz 是计算机科学专业的研究生，从高中起他就开始使用开放源码技术。从 GNOME 1.0 出现开始，他就成为了 GNOME 桌面的用户，而 2.0 版一发布，他就爱上了它，并了解到使用 GTK+ 能够开发他自己喜欢的桌面。