第３章 从使用者介面的面貌概观Ｘ
在本章，我们将观察重点摆到系统控制的使用者介面，例如，系统如何显示有人使用它，以及包含那些结构等。
Ｘ设计的目标之一就是能支援许多不同型式的使用者介面，一般其它的视窗系统提供特殊的交谈方法，而Ｘ则提供一般性的架构，让系统建立者(system builder)据以建造所需的交谈的风格。例如，在一个Ｘ系统中你可藉从选单中选一个动作来构建视窗，但其他对视窗的操作则全靠滑鼠来做，这种弹性允许系统开发者(developers)完全在Ｘ的基础上产生全新的介面，也因为介面并未内建於视窗系统，因此使用者在任何时刻根据他们特别的需求可选用适当的介面。例如，对於完成一些相同的工作 -- 建立、移动、重定大小萤幕上的视窗，初学者较老手喜欢简单的系统，而Ｘ可分别提供最适合他们的使用者界面。
使用者界面分为两个部份：
管理界面：命令最高层的视窗如何在萤幕上建构或重建构(re-configured),也就是说，如何管理你的案头。
应用界面：决定你和应用程式间交谈的”风格”(style)： 你如何利用视窗系统的设备程式来控制应用程式及输入资料给它。
3.1 管理界面：视窗管理器
管理界面(management interface)是系统的一部份，用以控制你萤幕上最上层的视窗（换句话说：如何重新建构你的案头），这个部份在系统中称之为视窗管理器(window manager)，它的功能有改变视窗的大小或位置、将视窗在堆叠 (stack)中重新安排位置、或将视窗改变成表徵图 (icon) 等等。
在Ｘ中，视窗管理器只是另一个client程式而已，它以及系统介面的发展，和server是完全分开的，因此你可以更换它们，这类似於Unix系统中的shell命令列直译器(interpreter) ：shell 只是一个使用者处理程式(process) ，如果你改变它，你也改变了系统的使用者介面。
3.1.1 手动的和自动的视窗管理器
有两类的视窗管理器：手动的和自动的。手动的视窗管理器，视窗在萤幕上的位置和大小完全由使用者控制，手动的视窗管理器只是使用者用来完成工作的工具，大部份的手动视窗管理器允许应用视窗重叠。
相对的，自动的视窗管理器尽可能的由它自己来控制案头，对於萤幕的布置尽可能让使用者少插手。它在新建立一个视窗时自动决定视窗的大小和位置，和当视窗移动时如何重新安排其馀的视窗，通常自动的视窗管理器将萤幕分成一块块像磁砖一样(tile)的区域，也就是说安排应用视窗彼此不会重叠，而且尽量占用最多的萤幕空间。
手动的视窗管理器如何工作 -- 攫取(Grabbing)
通常当你告诉手动的视窗管理器你要完成什麽动作时，是藉著使用选单或者结合了按滑鼠的按钮和移动指标，例如，重新摆放一个视窗的位置，你可以移动指标进入视窗，按住左边的按钮，移动指标然後在新位置松开按钮，视窗管理器是如何知道这些滑鼠 "事件" 的意图的？或是换个角度，server是如何知道 "事件" 是来自应用视窗或视窗管理器？
答案是由视窗管理器告知server有哪些特定的 "事件" （碰触按钮等等）需要被送达，这和哪一个视窗发生的无关，这种处理称之为攫取(Grabbing)，视窗管理器可以指定哪一个滑鼠按钮希望被攫取，而这攫取发生在滑鼠的按钮被按下且键盘上一些特定的键（一般称为修饰键(modifer) ）也被按住（例如当CONTROL 和SHIFT 两个键被按住时且滑鼠中间的按钮被按下），当按钮被按下时，攫取开始动作，server送出所有滑鼠的事件（包括滑鼠的移动事件）到视窗管理器直到按钮再度松开，视窗管理器把这些 "事件" 的资料解释成来自使用者的指令来工作。以移动视窗为例，视窗管理器在按钮按下时被告知指标的 位置，而当按钮松开时再度被告知，对指标的位移做一些简单计算便可据以移动视窗。
有一件事需要使用者配合，那就是滑鼠和修饰键组合而成的攫取不应该为应用程式所知道，所以必需确定视窗管理器这种攫取键的组合不会和应用程式冲突，大多数的视窗管理器可以很容易的定义这些攫取的组合键，而保留给它自己使用。
3.1.2 视窗管理器额外提供的功能
视窗管理器除了具有重新建构视窗的基本功能外，也提供额外的功能改进介面的品质，通常，加入额外功能的目的是为了降低键盘输入的需要，而改成尽量多用指标。
一个常见的功能是提供一个你自己可以建构的一般性选单，这样你只要选取一个选单选项便可启动视窗应用程式。这个启动的命令通常包含了指示应用视窗在何处出现，大小多少，本文用什麽颜色等等。所以应用程式不需要太多的使用者输入便能启动。一个常见的选单用法为当你在网路上工作时，你可以定义一个选单列出所有你在网路上可用的主机，如此你便可藉著在选单上选择主机名称便能和任一主机建立连接。
3.1.3 视窗管理器和表徵图
当一个视窗转换成一个表徵图时，表徵图是如何来的？视窗又发生了哪些事？
表徵图的结构非常的简单，它只是视窗的代表图案，当系统表徵图化(iconify)一个应用视窗，视窗管理器只是不对应出(unmap) 这视窗（也就是说，告诉server不再显示这个视窗到萤幕上）而把表徵图视窗对应出来。解除表徵图化(deiconify)则把上述的处理反过来。视窗管理器可以办得到的原因是它没有” 存取控制”(Access control)或许可限制来防止一个client（例如视窗管理器）不对应出其它的client的视窗，所有在同一个server上的client都可以对任意视窗或多或少做一些动作。
[1] [2] 下一页
视窗管理器通常提供预设的表徵图，但是client可以提供它自己的表徵图并建议使用它，有些视窗管理器接受这个要求，有些则忽略不接受仍用自己的表徵图，只把这个需求当作给视窗管理器的暗示(hint)。
当应用程式被表徵图化，它的主视窗便不再被对应出来，如果视窗管理器因任何理由中断了，则这个视窗永远也无法再对应出来了。要避免这点，当视窗管理器表徵图化一个视窗时，它把这个视窗加入一个名为save set的名单中，这个名单由server负责维护，如此当视窗管理器被中断时便可重新对应出来。
3.1.4 应用程式传递建构资讯给视窗管理器
就如同要求显示一个特定的表徵图一般，应用程式也能传递其它的暗示或建构资讯给视窗管理器，这包括：
. 应用程式和表徵图视窗的名称。
. 当应用程式和表徵图视窗被建立时，它们在萤幕上位置的资讯。
. 对视窗大小的限制（例如，client可以宣告”我所占用的视窗大小绝不可小於宽度若干x 长度若干”）。
. 对视窗重定大小的特别要求（例如，一个显示本文的视窗，可以要求在重定大小时按特定的间隔放大或缩小，以使得视窗内的字元永远是完整的一个，不致视窗边框的那一行 (列) 有半个字的情况出现。）。
这种将讯息传递给视窗管理器的结构称之为性质结构(property mechanism)，下一节我们会讨论它。
我们可以注意到大部份重定大小或表徵图化的事是由视窗管理器做的，这是因为它是一个公有的client，任何client均可随意重定大小，但如果所有client都这样做，便会造成混乱，因此要这些应用程式和平共存的原则是：不要自行重定大小，把它交给视窗管理器，也就是让使用者去决定。
在第６章中我们会看到一个视窗管理器uwm 如何使用。
3.2 应用程式介面和工具箱
应用程式介面决定了使用者和应用程式间交谈的风格，举例来说，如何用指标选一个选项等，Ｘ不提供标准的应用程式介面，只提供基本的结构以便建造它们。
当那些具有一贯性的应用程式介面被放在一起，便叫做工具箱(toolkit)，它是基础视窗系统软体中最高最有效率的层次，较低层次的细节，被隐藏起来，因此简化程式和维持介面的一贯风格变得容易执行，当使用者控制应用程式时好像有一套”虚拟文法(virtul grammer)”一般，需要注意很重要的一点是，工具箱在编译程式的时候被指定，所以一个client的应用程式介面在编译的时候就被决定了，如果不重新编译便无法改变。
M99v 版的Ｘ大多数的应用程式均使用标准的工具箱和一套来自M99v 的工具箱软体构成要素，这造成你可以得到一致性的介面。除此之外，有些结构更提供了定制的应用程式操作方法和设定它们的预设值。
3.3 其它的系统面貌
在本节中，我们讨论将应用程式之间传递资讯所用的性质结构(property mechanism)，视窗的树状阶层组织，和Ｘ不包含在作业系统中的优点。
3.3.1 client之间的通讯 -- ”性质”
client和server之间的通讯是藉著送出 "需求" 和接收 "事件" ，但有时client需要和其它的client传递资讯，例如，正常的应用程式需要告诉视窗管理器它的位置和大小，这就需要Ｘ的性质结构了。
”性质”是一小段资料的名称，这一小段资料存在server中且关联到一个特定的视窗，任何client均可向server查询某一特定视窗”性质”的值。
让我们看一个client如何把它所喜欢的表徵图名称传递给视窗管理器的范例：client把表徵图名称存到这个视窗的WIM_ICON_NAME ”性质”去，当视窗管理器执行表徵图化这个应用视窗时，它会去找这个应用视窗的WIM_ICON_NAME的”性质”，而後显示”性质”中的表徵图名称。
应用程式也可以和不是视窗管理器的其它的应用程式通讯，一个常见的例子是在分属不同应用程式的视窗之间做剪贴(cut-and-paste) 操作，一段本文从一个应用程式中”切下”(cut) 稍後再”贴”到另一
（出处：http://www.sheup.com）
上一页 [1] [2]
（出处：http://www.sheup.com）
上一页 [1] [2] [3]