级别： 初级 David Faure (faure@kde.org), KDE 开发人员, MandrakeSoft
2002 年 2 月 09 日 本文讨论 KParts — 一种在 KDE（K 桌面环境（K Desktop Environment））中建立的图形组件的体系结构。KParts 通过将图形组件嵌入应用程序的窗口使需要同一功能的应用程序共享一个组件。 本文将 KParts 与其它组件模型（如 CORBA）进行比较，并描述了 KParts 中使用的主要概念，包括操作、插件、部件管理器和 GUI 合并。
K 桌面环境或 KDE 是一种用于 Linux/UNIX 的、易于使用的、开放源码的图形环境，它适用于所有 Linux 分发版（distribution）。 以 Qt 工具箱为基础，KDE 是用于图形应用程序的功能强大的 C++ 开发平台。Qt 提供窗口构件、许多实用程序类和一个核心对象模型。KDE 提供一个集成的网络透明性、进程间通信、 完整的 HTML 浏览器和这里介绍的 KParts（图形组件的体系结构）。 组件的概念是当今软件设计中的关键概念。KParts 通过将图形组件嵌入应用程序的窗口使需要同一功能的应用程序共享这个任务的组件。
本文讨论 KParts 究竟是什么、为什么需要它以及它是如何工作的。本文把 KParts 与其它组件模型（特别是进程外的组件模型）作比较， 然后描述 KParts 中使用的主要概念，包括操作、插件、部件管理器和 GUI 合并。本文以通过展示如何在 KDE 中（特别是在 Konqueror 和 KOffice 中）使用 KParts 组件模型来结束。
KParts 组件：查看器和编辑器
KParts 特别适用于任何数据类型的图形组件（如查看器和编辑器）。 示例查看器，也称作“只读部件”，是 Konqueror 中的目录视图、HTML 浏览器窗口构件、图像查看器、DVI 查看器、PS/PDF 查看器和文本查看器。编辑器，或称作“读写部件”，是可以修改数据的组件，如文本编辑器和 KOffice 应用程序。
组件的最重要部分是它的界面。例如，KDE 的文件管理器 Konqueror（见下图 1）能够嵌入表示任何类型文件的各种查看器，因为所有查看器都提供相同界面。
图 1. 正在运行的 Konqueror 文件管理器
图形组件不仅仅是一个窗口构件，例如 Qt 提供的那些窗口构件。窗口构件和组件之间的主要差异是： 组件带有附加用户界面项，如菜单项和工具栏按钮，托管应用程序可将它们集成到自己的用户界面中。
理解 KParts 不是一个万能的对象模型很重要。因为 KDE 使用 QObject，而它是 Qt 和 KDE 中所有对象的基类。QObject 提供所有对象的公共功能：命名、父／子关系、信号与槽、事件模型和特性。
为什么使用组件？
创建组件的主要目的是能够在需要相似功能的应用程序中使用同一个组件。 但即使仅在单一应用程序中使用组件时，组件体系结构所给予的高度的模块化也会使并行工作变得更加容易， 并且更便于确保新功能部件的引入不会引起倒退（例如，新功能部件不会破坏现有的功能部件）。 例如，不必更改 Konqueror 本身的任何一行代码，Konqueror 获得了一个带有附加工具栏按钮和菜单项的全新的目录视图，用于管理与“并发版本系统（Concurrent Version System(CVS)）”服务器相关的文件。
查找一个适当的 KParts 组件
在应用程序之间共享任何事物的传统方法是将代码放在一个共享库中并从应用程序二进制码与之链接。 这种方法允许方便地访问共享代码。然而，这种方法不灵活， 因为它不允许在安装应用程序之后安装组件。要获得对组件的运行时访问权， 应用程序动态地定位并打开包含组件的共享库。
如果应用程序没有某种数据类型的内置查看器或编辑器，那么它需要根据组件的功能查找一个适合于打开此类型数据的组件。 每个组件将它实现的服务类型（例如“Viewer”）、文件类型（例如“Image”）和帮助 KDE 定位并打开包含该组件的库的各种详细信息一起发布到一个“service”文件中。KDE Trader（KDE 库提供的工具）提供了查询已安装的 service 文件的方法， 以查找哪些服务与应用程序给出的标准匹配。
例如，当在 KOffice 应用程序中单击 Print Preview 按钮时， 它将向 Trader 查询实现与文件类型“postscript”相关的查看器的服务。如果可以使用任何这样的组件（KGhostView 提供了一个），那么 Print Preview 窗口将嵌入它；否则，它会启动一个独立的 PostScript 查看器作为退路。
四个 KParts 概念
KParts 是基于标准 KDE/Qt 对象（如 QWidget 和 KMainWindow）的 KDE 部件的框架。它定义了一套非常简单的类：Part、Plug-in、MainWindow 和 Part Manager。
-
Part是图形 KDE 组件的名称。它提供一个窗口构件，当然还提供给予 Part 功能访问权的操作， 以及描述这些操作在用户界面中的布局的 XML 文件。
-
Plug-in是一小块功能，它不是由嵌入的窗口构件实现的， 而是定义合并到应用程序的用户界面中的一些操作 — 例如 KSpread（KOffice 的电子表格程序）的 Calculator Plug-in。然而，它可以是图形的，象对话框或单独的弹出窗口， 也可以是特定于应用程序的插件并作用于该应用程序本身，如字处理器的拼写检查程序。
-
MainWindow是一个特殊的 KDE 主窗口，它有一些用于嵌入 Part 的附加功能：支持 MainWindow 插件并给予对窗口标题和状态栏的 Part 访问权。标准的 KDE 主窗口，甚至是对话框都可以嵌入 Part，但不带那些附加功能部件。
-
Part Manager是一种更抽象的对象，它的任务是处理 Part 的激活和取消激活。 当然，这仅对于嵌入了多个 Part 的 MainWindow 有用，如 Konqueror（其中的每个视图都是一个 Part）或 KOffice 文档（其中的主文档和嵌入的文档都是 KParts 组件）。 那些仅嵌入了它们自己的部件的独立查看器不需要 Part Manager。
对比 KParts 与 COM/CORBA 模型
开始开发 KDE 2.0 时，KDE 团队专注于使用 CORBA，它是一种分布式对象通信的中间件框架。 然而，在开发期间，结果表明 CORBA 是一种设计得十分完整的体系结构，它适用于大型和高等待时间的应用程序（如数据库应用程序） 而不适用于象用户界面这样的需要快速响应的任务。CORBA 天生就是分布式的，如果需要分布式对象，那么它可以带来好处； 但是，如果不需要分布式对象并且您不再需要它们来嵌入组件，那么它会是一个负担。
CORBA 曾被用于两种完全不同的事情：图形组件嵌入和进程间通信（IPC）。现在，KParts 提供前者，桌面通信协议（Desktop Communications Protocol，DCOP）提供后者。 桌面显然需要进程间通信（例如，要使应用程序之间的数据和设置同步），但这与组件嵌入无关。
与 CORBA 比较，使用 KPARTS 有以下优点
- KParts 组件已变得易于开发和使用。 另一方面，CORBA 有一条非常陡峭的学习曲线，它包括必须学习另一种语言（IDL）和新的数据类型。
- 与 CORBA 一个进程拥有一个组件相比，KParts 体系结构是“轻量级”的： 单一进程拥有应用程序和多个组件。
- KParts 提供了文档管理（利用内置网络透明性来跟踪已修改的状态并支持装入和保存）。
- KParts 提供了紧密的集成（用户界面合并和一致外观）。
- 更容易地将正在进程内的组件与使用本机工具箱的所有窗口构件和正在同步的调用集成。
- 一些分布式对象体系结构（如 KDE 以前的基于 CORBA 的体系结构）涉及对图形对象的 API 的完全重定义： 例如，从组件创建菜单项不同于用本机工具箱创建菜单项。另一方面，KParts 不需要重新编写现有组件就可通过 KParts 体系结构访问它们。
与 CORBA 比较，使用 KParts 有以下缺点
- KParts 组件不能与 CORBA/COM 应用程序通信。
- KParts 仅特定于 KDE 和 C++。
- 单一组件会降低整个应用程序的性能。
- 库装入和卸装引入一些问题，如需要注意静态对象。
KParts 的主要限制是它无能力使用以其它语言编写或使用其它工具箱编写的组件。然而，针对这一目的，已经开发了一个 KParts 的进程外组件模型，称为 XPart。 应用程序把它当作是一个正常的 KParts 组件（在同一个进程内），但实际上它是与另一个进程（使用 DCOP）通信的代理， 那个进程才是该组件真正所在的位置。这一技术正用于开发基于 vi 的文本编辑器组件 — 但它仍处于开发阶段。
KParts 框架
“操作”是图形组件的主要概念。 如果应用程序需要在 Edit 菜单中有“Copy”菜单项，以及“Copy”的工具栏按钮，传统方法是分别创建它们， 并确保它们同时启用或禁用。
因为这两项都属于同一个操作 — 复制，所以操作后面的想法是要创建单一操作，以便应用程序仅需要处理一项。 将该操作“插入”到菜单时，就创建了一个菜单项，将它插入到工具栏时，就创建一个按钮。 这种方法还会使整个用户界面是可配置的， 而且在 XML 文件中描述的 GUI 布局与应用程序代码分开。例如，KDE 的工具栏编辑器只保存 XML 文件的已修改版本， 它定义哪些操作应该放在工具栏上以及它们的顺序。 我们将这种技术称为“XML-GUI”。
GUI 合并
当应用程序嵌入一个 Part 时， 它将 Part 的用户界面合并到其自己的用户界面中。在非 Linux 世界中， 众所周知的 GUI 合并示例是当一个文档嵌入另一个文档时由 Microsoft Office 完成的菜单合并。
在 KDE 中，菜单合并使用先前描述的 XML-GUI 技术。所有应用程序和所有组件都在 XML 文件中定义其用户界面的布局。 当将 Part 嵌入应用程序或将 Plug-in 嵌入 Part 时，使用托管应用程序中的可选预定义合并点来合并这两个 XML 树。
操作和 GUI 合并的概念已经扩展到所有 KDE，甚至扩展到与 KParts 无关的应用程序。 标准的 GUI 布局与应用程序定义的布局合并，这样它就不需要将 New、Open、Save、Close 等操作指定到 File 菜单中， 或者将 Copy、Cut、Paste 等操作指定到 Edit 菜单中。如果应用程序只创建 Cut 操作，那么它会 自动进入 Edit 菜单，除非应用程序在它的 XML 文件中重设该菜单的标准布局。这使图形 KDE 应用程序的开发变得非常简单。
Konqueror 和 KOffice 中使用的 KParts 扩展
KDE 提供了许多 KParts 组件，包括 HTML 查看器、文本编辑器、图像查看器和 Konqueror 的目录视图。Konqueror 本身基本上是所有只读部件的通用宿主。KParts 的设计尽可能简单：在普通的“只读部件”中，部件只能显示应用程序传递给它的 URL 的内容。这是任何查看器的主要功能，应用程序只需要它就可显示图像、PostScript 文件等。 然而，这对于诸如将 HTML Part 完全集成到浏览器中等任务是不够的。
为了更好地与浏览器集成，KParts 定义了一个称为
BrowserExtension的附加接口，并且可以由组件来实现它。 扩展允许组件在用户单击浏览器中的 Back 和 Forward 按钮时保存并恢复它们的状态， 并允许部件请求打开 URL（例如，当单击链接时）。
注意，这是一个正在运行的示例，与子类化相对，它涉及如何通过聚合对象 — 将BrowserExtension 添加到 ReadOnlyPart — 来扩展功能。聚合允许添加任意数量的扩展，而无需定义子类的所有可能的组合。
KParts 还用于更高级别的接口中，如 TextEditor 接口。前者是对文本编辑器的 API 建模的完整接口， 以使应用程序可以互换地使用实现这一接口的任何可用文本编辑器。vi 用户喜欢使用 vi 文本编辑器组件（这种组件正处于开发阶段）在 KMail 中输入邮件。通用的 ImageViewer 接口也正处于开发阶段。
但利用 KParts 的最大的软件项目是 KOffice。KParts 是 KOffice 中用于将文档嵌入其它文档（如将 KSpread 中的电子表格对象嵌入 KWord（字处理器）文档）的新对象框架。KOffice 文档是 KParts 组件，除了 KOffice 体系结构允许单个文档有多个视图， 而 KParts 只允许一个部件有一个窗口构件。选择基于 KParts 建立 KOffice 文档模型，就有可能将 KOffice 文档作为简单的只读部件查看，并允许将只读 KOffice 文档嵌入 Konqueror 来查看它们。因为 KParts 组件是进程内的，所以处理容器部件（上面示例中的字处理器）和已嵌入的部件（上面示例中的电子表格）没有速度差异。
KParts 是允许在 KDE 中有如此高集成度的组件模型，它使重用现有组件来查看或编辑任何数据类型变得很容易。 您可以只用五行简单的代码就可以创建一个“通用查看器”窗口，以便在应用程序中显示任何文件类型。 使用 KParts，任何 KDE 应用程序都可以获得对 KDE 提供的为数众多的组件的访问权。 而且任何人都可以开发将由 Konqueror 和其它基于 KParts 的应用程序使用的组件以显示新的文件类型，例如， 公司具有特定数据格式的自用文件。
下一步
请继续留意我们即将发布的 KParts 教程， 它将演示如何创建和使用 KParts 组件。同时，请参考下面的参考资料以学习有关 KDE 和 KParts 的更多知识。
参考资料
关于作者  | | | David Faure 是为 MandrakeSoft 工作的一名法国 KDE 开发人员；他维护 Konqueror、文件管理器和 Web 浏览器。他还从事于 KDE 库（组件技术和网络透明性）和 KOffice（框架和 KWord）的开发工作。David 为
Linux Magazine France编写了有关 KDE 编程的系列文章以及公开的
KDE 2.0 Development书籍的其中一章。他在 KParts 方面的经验直接源于他参与了 KParts 的设计和开发。可以通过
faure@kde.org与 David 联系。
|
对本文的评价
| 
