从使用者介面的面貌来概观Xwindow

   来源：赛迪网技术社区    作者：caohong

我们将观察重点摆到系统控制的使用者介面，例如，系统如何显示有人使用它，以及包含那些结构等。

Ｘ设计的目标之一就是能支援许多不同型式的使用者介面，一般其它的视窗系统提供特殊的交谈方法，而Ｘ则提供一般性的架构，让系统建立者(system builder)据以建造所需的交谈的风格。例如，在一个Ｘ系统中你可藉从选单中选一个动作来构建视窗，但其他对视窗的操作则全靠滑鼠来做，这种弹性允许系统开发者(developers)完全在Ｘ的基础上产生全新的介面，也因为介面并未内建於视窗系统，因此使用者在任何时刻根据他们特别的需求可选用适当的介面。例如，对於完成一些相同的工作 -- 建立、移动、重定大小萤幕上的视窗，初学者较老手喜欢简单的系统，而Ｘ可分别提供最适他们的使用者介面。

使用者介面分为两个部份：

管理介面：命令最高层的视窗如何在萤幕上建构或重建构(re-configured),也就是说，如何管理你的案头。

应用介面：决定你和应用程式间交谈的”风格”(style)： 你如何利用视窗系统的设备程式来控制应用程式及输入资料给它。

管理介面：视窗管理器

管理介面(management interface)是系统的一部份，用以控制你萤幕上最上层的视窗（换句话说：如何重新建构你的案头），这个部份在系统中称之为视窗管理器(window manager)，它的功能有改变视窗的大小或位置、将视窗在堆叠 (stack)中重新安排位置、或将视窗改变成表徵图 (icon) 等等。

在Ｘ中，视窗管理器只是另一个client程式而已，它以及系统介面的发展，和server是完全分开的，因此你可以更换它们，这类似於Unix系统中的shell命令列直译器(interpreter) ：shell 只是一个使用者处理程式(process) ，如果你改变它，你也改变了系统的使用者介面。

手动的和自动的视窗管理器

有两类的视窗管理器：手动的和自动的。手动的视窗管理器，视窗在萤幕上的位置和大小完全由使用者控制，手动的视窗管理器只是使用者用来完成工作的工具，大部份的手动视窗管理器允许应用视窗重叠。

相对的，自动的视窗管理器尽可能的由它自己来控制案头，对於萤幕的布置尽可能让使用者少插手。它在新建立一个视窗时自动决定视窗的大小和位置，和当视窗移动时如何重新安排其馀的视窗，通常自动的视窗管理器将萤幕分成一块块像磁砖一样(tile)的区域，也就是说安排应用视窗彼此不会重叠，而且尽量占用最多的萤幕空间。

手动的视窗管理器如何工作 -- 攫取(Grabbing)

通常当你告诉手动的视窗管理器你要完成什麽动作时，是藉著使用选单或者结合了按滑鼠的按钮和移动指标，例如，重新摆放一个视窗的位置，你可以移动指标进入视窗，按住左边的按钮，移动指标然後在新位置松开按钮，视窗管理器是如何知道这些滑鼠 "事件" 的意图的？或是换个角度，server是如何知道 "事件" 是来自应用视窗或视窗管理器？

答案是由视窗管理器告知server有哪些特定的 "事件" （碰触按钮等等）需要被送达，这和哪一个视窗发生的无关，这种处理称之为攫取(Grabbing)，视窗管理器可以指定哪一个滑鼠按钮希望被攫取，而这攫取发生在滑鼠的按钮被按下且键盘上一些特定的键（一般称为修饰键(modifer) ）也被按住（例如当CONTROL 和SHIFT 两个键被按住时且滑鼠中间的按钮被按下），当按钮被按下时，攫取开始动作，server送出所有滑鼠的事件（包括滑鼠的移动事件）到视窗管理器直到按钮再度松开，视窗管理器把这些 "事件" 的资料解释成来自使用者的指令来工作。以移动视窗为例，视窗管理器在按钮按下时被告知指标的位置，而当按钮松开时再度被告知，对指标的位移做一些简单计算便可据以移动视窗。

有一件事需要使用者配合，那就是滑鼠和修饰键组合而成的攫取不应该为应用程式所知道，所以必需确定视窗管理器这种攫取键的组合不会和应用程式冲突，大多数的视窗管理器可以很容易的定义这些攫取的组合键，而保留给它自己使用。

 

视窗管理器额外提供的功能

视窗管理器除了具有重新建构视窗的基本功能外，也提供额外的功能改进介面的品质，通常，加入额外功能的目的是为了降低键盘输入的需要，而改成尽量多用指标。

一个常见的功能是提供一个你自己可以建构的一般性选单，这样你只要选取一个选单选项便可启动视窗应用程式。这个启动的命令通常包含了指示应用视窗在何处出现，大小多少，本文用什麽颜色等等。所以应用程式不需要太多的使用者输入便能启动。一个常见的选单用法为当你在网路上工作时，你可以定义一个选单列出所有你在网路上可用的主机，如此你便可藉著在选单上选择主机名称便能和任一主机建立连接。

视窗管理器和表徵图

当一个视窗转换成一个表徵图时，表徵图是如何来的？视窗又发生了哪些事？

表徵图的结构非常的简单，它只是视窗的代表图案，当系统表徵图化(iconify)一个应用视窗，视窗管理器只是不对应出(unmap) 这视窗（也就是说，告诉server不再显示这个视窗到萤幕上）而把表徵图视窗对应出来。解除表徵图化(deiconify)则把上述的处理反过来。视窗管理器可以办得到的原因是它没有”存取控制”(access control)或许可限制来防止一个client（例如视窗管理器）不对应出其它的client的视窗，所有在同一个server上的client都可以对任意视窗或多或少做一些动作。

视窗管理器通常提供预设的表徵图，但是client可以提供它自己的表徵图并建议使用它，有些视窗管理器接受这个要求，有些则忽略不接受仍用自己的表徵图，只把这个需求当作给视窗管理器的暗示(hint)。

当应用程式被表徵图化，它的主视窗便不再被对应出来，如果视窗管理器因任何理由中断了，则这个视窗永远也无法再对应出来了。要避免这点，当视窗管理器表徵图化一个视窗时，它把这个视窗加入一个名为save set的名单□，这个名单由server负责维护，如此当视窗管理器被中断时便可重新对应出来。

应用程式传递建构资讯给视窗管理器

就如同要求显示一个特定的表徵图一般，应用程式也能传递其它的暗示或建构资讯给视窗管理器，这包括：

. 应用程式和表徵图视窗的名称。

. 当应用程式和表徵图视窗被建立时，它们在萤幕上位置的资讯。

. 对视窗大小的限制（例如，client可以宣告”我所占用的视窗大小绝不可小於宽度若干x 长度若干”）。

. 对视窗重定大小的特别要求（例如，一个显示本文的视窗，可以要求在重定大小时按特定的间隔放大或缩小，以使得视窗内的字元永远是完整的一个，不致视窗边框的那一行 (列) 有半个字的情况出现。）。

这种将讯息传递给视窗管理器的结构称之为性质结构(property mechanism)，下一节我们会讨论它。

我们可以注意到大部份重定大小或表徵图化的事是由视窗管理器做的，这是因为它是一个公有的client，任何client均可随意重定大小，但如果所有client都这样做，便会造成混乱，因此要这些应用程式和平共存的原则是：不要自行重定大小，把它交给视窗管理器，也就是让使用者去决定。

应用程式介面和工具箱

应用程式介面决定了使用者和应用程式间交谈的风格，举例来说，如何用指标选一个选项等，Ｘ不提供标准的应用程式介面，只提供基本的结构以便建造它们。

当那些具有一贯性的应用程式介面被放在一起，便叫做工具箱(toolkit)，它是基础视窗系统软体中最高最有效率的层次，较低层次的细节，被隐藏起来，因此简化程式和维持介面的一贯风格变得容易执行，当使用者控制应用程式时好像有一套”虚拟文法(virtul grammer)”一般，需要注意很重要的一点是，工具箱在编译程式的时候被指定，所以一个client的应用程式介面在编译的时候就被决定了，如果不重新编译便无法改变。

MIT 版的Ｘ大多数的应用程式均使用标准的工具箱和一套来自MIT 的工具箱软体构成要素，这造成你可以得到一致性的介面。除此之外，有些结构更提供了定制的应用程式操作方法和设定它们的预设值。

其它的系统面貌

在本节中，我们讨论将应用程式之间传递资讯所用的性质结构(propertymechanism)，视窗的树状阶层组织，和Ｘ不包含在作业系统中的优点。

client之间的通讯 -- ”性质”

client和server之间的通讯是藉著送出 "需求" 和接收 "事件" ，但有时client需要和其它的client传递资讯，例如，正常的应用程式需要告诉视窗管理器它的位置和大小，这就需要Ｘ的性质结构了。

”性质”是一小段资料的名称，这一小段资料存在server中且关联到一个特定的视窗，任何client均可向server查询某一特定视窗”性质”的值。

让我们看一个client如何把它所喜欢的表徵图名称传递给视窗管理器的□例：client把表徵图名称存到这个视窗的WIM_ICON_NAME ”性质”去，当视窗管理器执行表徵图化这个应用视窗时，它会去找这个应用视窗的WIM_ICON_NAME的”性质”，而後显示”性质”中的表徵图名称。

应用程式也可以和不是视窗管理器的其它的应用程式通讯，一个常见的例子是在分属不同应用程式的视窗之间做剪贴(cut-and-paste) 操作，一段本文从一个应用程式中”切下”(cut) 稍後再”贴”到另一个应用视窗，”性质”在此被用到，”性质”依序编成”CUT_BUFFER0”，”CUT_BUFFER1”…等等，所有的应用视窗便可藉此交换资料。

最後一个例子是称为resources 的”性质”，它被用来定义应用程式的预设值设定，在根视窗(root window) 中有一个名为RESOURSE_MANAGER的性质存放著所有设定的名单，它会被所有的应用程式存取，用来做是否要执行任何设定的依据。

在Ｘ中视窗的阶层性

本节描述视窗在系统中的组织及如何建立，和对应用程式的影响。

所有在Ｘ中的视窗都可视为一个树状结构阶层 (hierarchy)的一部份，树的根部便是根视窗，涵盖了整个萤幕，应用视窗都是根视窗的子代(children)，上层的视窗可以拥有它自己的子视窗。在Ｘ的设计理念下，制造一个视窗非常容易，你可以利用视窗来控制选项，像选单、卷动棒(scrollbars)、控制钮(control button)等等，即使是大量也无妨，例如像试算表中的一个cell等。这种观点从程式设计师的角度大於使用者，但的确对使用者当他”定制”(customising) 特定的程式时有影响，在本章以後的章节会再度提到。

为了允许应用程式有子视窗，Ｘ提供了大量的设备程式供client程式使用，如此不但能达成一致性，也避免了相同的需求造成了重复的工作，例如像图3-1的下拉式选单，可以在应用程式中以一致子视窗完成，这个子视窗有它们自己的选单选择方框(pane)，和用以侦测使用者碰触滑鼠按钮的标准结构，如果没有子视窗，复杂的程式和输入处理将无可避免。

子视窗的位置和大小并不受父视窗的限制，子视窗可大可小，可以大过父视窗或只占父视窗的一部份，但是它会被父视窗剪裁(clipped) ，也就是说，子视窗所有超出父视窗的部份将会消失不见。

在实际的应用上，你可以将上层的视窗定义成几乎占住整个萤幕，就不必

担心子视窗有些部份会看不到了。

另外一种方式就是把下拉式选单定义成为根视窗的子视窗，如此选单便可以比应用视窗还大。

Ｘ不是深植於作业系统

不像其它大多数的系统，Ｘ并非深植(embedded)於作业系统中，而只是比使用者层次稍高而已。更精确地说，Ｘ不需要深植於系统，虽然有些制造厂商可能是为了效率(performance) 的理由将server和作业系统结合在一起，但不深植於作业系统的结构有下列利益：

．易於安装和改版，或甚至去除。这种工作不需要重新启始系统，也不会对其它应用程式造成干扰。

．第三集团很容易支援加强它的功能。例如你的制造厂商提供的系统不够好，你可以向别人买更好或更快的版本。

．Ｘ不会指定作业系统，因此成为一种标准，这也是第三集团发展软体的原动力。

．为了发展者利益。在server上发展工作时，当程式当掉只会当掉视窗系统，不会造成机器的损坏或作业系统核心的破坏，没有作业系统核心码的程式也较易除错。

结论

在本章中我们描述了许多Ｘ提供的使用者介面，我们介绍了你用以管理案头的程式 -- 视窗管理器的概念，也描述了被用来做使用者和client应用程式间交互作用的设备程式。我们介绍了用来做client间通讯的性质结构，Ｘ视窗的阶层结构对系统的影响，最後对视窗系统不深植於作业系统的好处做一摘要。