X Window核心协议

前言： X Window核心协议是X Window系统的基础协议，它是一个以位图显示的网络化视窗系统，用来在Unix、类Unix和其他操作系统上建立使用者图形界面。X Window系统基于主从式模型：单一服务器控管硬件的输出入，如屏幕、键盘和鼠标；所有的应用程式都被视作客户端，使用者之间透过服务器来互动。互动部分由X Window核心协议来管理。还有其他与X Window系统有关的协议，有的建立在X Window核心协议之上的，有的是独立的协议。 X Window源于1984年的麻省理工学院（目前所发布的X11发表于1987年9月）。设计者鲍伯·斯凯夫勒（BobScheifler）和吉姆·杰提斯（JimGettys）早期对核心协议的原则是“建立机制，而不是方针”，所以核心协议并未规定客户端之间以及客户端和使用者之间的互动规范。这部分则由其他的独立规格所规范，如ICCCM、freedesktop.org规范，且可由所使用的特定组件工具包自动强制执行。 一：概观 服务器和客户端之间的通讯，是由通道上的交换封包所完成。由客户端建立连线，且由客户端发送第一个封包。封包中包括将要使用的位元顺序、协议版本方面的资讯，以及客户端期望服务器使用的认证种类。服务器以回传封包来答复，封包中陈述接受或拒绝连线，或要求进一步的验证。如果接受连线，接受封包内会包含客户端接下来和服务器互动所需的资料。 客户端和服务器之间的互动范例。建立连线之后，在客户端和服务器的通道上，会有四种交换封包的类型： X Window核心协议客户端和服务器之间的互动范例 客户端和服务器之间的互动范例 1 请求：客户端请求服务器的资讯，或者请求服务器执行一个动作。 2 回应：服务器回应请求。但并非所有的请求都会产生回应。 3 事件：服务器传送事件给客户端。如：键盘或鼠标的输入，或移动、调整、显示视窗等。 4 错误：如果请求无效时，服务器会传送一个错误封包。因为请求是以排队方式处理，所以经由请求所产生的错误封包，并不会立即传送出去。 请求和回应封包可以有各种长度，事件和错误封包的长度则固定是32字节。 请求封包的编号顺序是以服务器的接收为顺序：来自客户端的第一个请求编号为1、第二个编号为2，依此类推。请求的序列编号中最小的有效16位元，包含在由请求所产生的回应和错误封包之中，如果有的话。它们也包含在事件封包中，以指出服务器正在处理或是刚刚完成的请求序列编号。 客户端和服务器之间的互动范例 二：视窗 在XWindow系统以及各种图形化使用者界面中，视窗即为一个顶层视窗。视窗也用来指视窗内部的视窗，这类视窗是父视窗的子视窗。图形化元件，如按钮、选单、图示等等，都是使用视窗来实现的。 视窗可能的放置情形如下图： 视窗 1是根视窗，与整个屏幕对应；2和3是顶层视窗；4和5是2的子视窗。超出父视窗的部分不会显示出来。客户端可请求建立一个视窗。更严谨的说，客户端可请求建立现存视窗的子视窗。所以客户端所建立的视窗，皆以树状结构组织（阶层结构）。树状结构的根即为根视窗，根视窗是服务器在启动时，所自动建立的特殊视窗。其余视窗都是根视窗的子视窗，顶层视窗就是根视窗下的第一个子视窗。如同所见，根视窗和屏幕同等大小，且在其余视窗的后面（被子视窗遮盖住）。 视窗里的内容并非在所有时候都能显示出来。更精确的说，在视窗移动、调整大小、被其他视窗遮盖、部分或整个视窗不可见时，视窗里的内容就有可能会被销毁。更精确的说，如果X服务器无法维护视窗内容的后备存放区（backingstore）时，这些内容就会遗失。客户端可请求为视窗进行维护的后备存放区，但服务器没有义务要这样做。因此，客户端不可假设已得到后备存放区的维护。若视窗有一部分未指出内容时，就会传送一个事件，通知客户端重绘那部分内容。 每个视窗都关联一组属性值（Attribute），如视窗的几何性质（大小和位置）、背景图、是否请求了后备存放区等等。协议中还包含用来给客户端检阅和改变视窗属性值的请求。 视窗可以是InputOutput（输出入）或InputOnly（仅输入）。前者是显示在屏幕上用于绘图的视窗，而后者并不显示在屏幕上，仅用来接受输入。 平常可看到视窗周围的装饰性框架和标题列（可能含有按钮），是由视窗管理器所建立的视窗，而非客户端所建立的。视窗管理器也处理与元件有关的输入，例如当使用者点击并拖曳视窗的边框时，便会调整视窗大小。客户端所建立的视窗，通常可以忽略视窗管理器所带来的变化。还有一个改变必须注意，那就是改变亲属关系的视窗管理器，几乎所有新式的视窗管理器，都会将顶层视窗的亲属关系改变到一个视窗（不是根视窗）里去。从核心协议的角度来看，视窗管理器是一个客户端，与其他的应用程式没有区别。 关于视窗的资料，可执行xwininfo程式来取得。加上-tree命令列参数，程式便会显示子视窗的树状结构，连同识别子和几何性质资料一起显示。 FVWM视窗的结构 三：图形映射和可绘区 图形映射（pixmap）是内存中可用来绘图的区域。与视窗不同，图形映射的内容并不会自动显示在屏幕上。不过图形映射的内容（或部分内容）可转换到视窗上，反之亦然。这就让双缓冲得以实作。大部分可在视窗上完成的图形化操作，也可以图形映射完成。 视窗和图形映射被统称为可绘区（drawable），且其资料内容都保留在服务器上。客户端可请求从服务器上，将可绘区的内容转换到客户端，反之亦然。 四：图形脉络和字体 客户端可请求很多种图形运算，如清空一块区域、复制一块区域到另一处，绘制一个点、线、矩形和文字。对清空而言，所有运算都有可能用在可绘区上（视窗和图形映射）。 图形脉络（graphiccontext）包括了对图形运算的大部分请求，图形脉络是一种结构，包含有图形运算的参数。图形脉络包含前景色、背景色、文字的字体，以及各种图形参数。当请求图形运算时，客户端就包含一个图形脉络。很明显的，并非所有的图形脉络参数都会参与运算：例如，字体对于直线的绘制不产生作用。 核心协议规格使用了服务器侧的字体。如字体是以档案形式存放，服务器经由本机的档案系统直接存取，或经由网络从字体服务器存取。客户端可向服务器请求有效的字体列表，且可请求服务器加载（没有的话）或卸载（客户端不再需要的话）字体。客户端可请求关于字体的资讯（例如，ascent字体），并以指定的字体来绘制指定的字串。 五：xfontsel xfontsel程式可让使用者检视字体的标记。 X Window核心协议xfontsel 程式可让使用者检视字体的标记 在X Window核心协议的层次上，字体的名称可以是任意的字串。X逻辑字体描述协定规范了如何根据字体的属性来命名。这些协定也规范了可附属于字体的选用属性之值（value）。 xlsfonts程式可输出存放在服务器上的字体列表。xfontsel程式可显示字体的标记，并让使用者选取字体的名称，以在其他视窗中贴上。 目前已不再重视服务器侧字体的使用，而转向客户端侧字体的使用。例如，借由支援Xft或cairo程式库，以及XRender扩充，改由客户端（而非服务器）绘制字体。客户端侧字体在核心协议中尚未给出规范 六：资源和识别 所有关于视窗的资料、图形映射、字体等等，皆存放在服务器上。客户端知道那些物件的识别子，和服务器互动时，物件以整数为名称。例如，当客户端希望建立一个视窗时，便指定一个识别子，并请求服务器建立一个视窗。服务器会建立一个视窗，并与指定的识别子关联。稍后客户端可使用这个识别子进行请求，例如在视窗上画上一个字串。以下存在于服务器上的物件，客户端可借由数值型的识别子得知： 视窗（Window） 图形映射（Pixmap） 字体（Font） 色彩映射（Colormap）（即颜色表，稍后描述） 图形脉络（Graphiccontext） 这些物件就称作资源。当客户端请求建立某一种资源时，同时也为资源指定了一个识别子。例如，为了建立一个新视窗，客户端指定了视窗的属性值（亲属关系、宽、高等等）和识别子，最后识别子会和视窗关联。 识别子是三个最高有效位为0的32位元整数。每一个客户端都有一组自己的识别子，其可用来建立新的资源。这组识别子是由服务器以包含在接受封包（传送给客户端的封包，通知已接受连线）中的两个整数所指定的。客户端以避免冲突的方式选取识别子：在视窗、图形映射、字体、色彩映射、图形脉络之中的两个物件，不可具有相同的识别子。 资源一经建立，其识别子就用于客户端向服务器请求与之有关的运算。部分运算会影响特定的资源（例如，请求移动视窗），其他的则要求存放在服务器上的资源资料（例如，请求视窗的属性值）。 识别子在服务器上是独一无二的，在多个客户端之间也不例外。例如，即使是由两个不同客户端所建立的视窗，也不会同时具有相同的识别子。即使某个物件不是由自己的客户端所建立的，只要指定相对应的识别子，就可存取另一个客户端所建立的任何物件。 连线到同一服务器的两个客户端，对同一资源可使用同一识别子。例如，若客户端建立一个0x1e00021识别子的视窗，并传送数值0x1e00021给其他的应用程式（透过任何有效的手法。例如，把数值存放在档案里，且这个档案可让其他的应用程式轻易存取），其他的应用程式即可对同一视窗进行操作。这个例子是来自XWindow版本的Ghostview：程式建立一个子视窗，在环境变量中存放其识别子，并呼叫Ghostscript；程式绘制 PostScript档案的内容，以显示在这个视窗上。 当建立资源的客户端关闭与服务器的连线时，资源就会正常的销毁。不过在关闭连线之前，客户端可以请求服务器不要销毁资源。 六：事件 事件是由服务器传送到客户端用以通讯的封包，传送一些客户端可能感兴趣的事情。例如，当使用者按下按键或点击鼠标时，便会传送一个事件。事件不只用于输入：例如，传送的事件表明特定视窗建立了新的子视窗。 每一个事件都会涉及到视窗。例如，当使用者的指标在视窗之内并点击时，这个事件就会涉及到那个视窗。事件封包中含有那个视窗的识别子。 客户端可以请求服务器传送事件给另一个客户端，这可用于客户端之间的通讯。例如，当客户端请求目前所选取的文字时，就会传送事件给客户端，以处理目前所持有的选取内容。 当再度观看内容已被销毁的区域时，有可能会传送Expose（显露）事件。而且在某些情况下，视窗的内容可能会被销毁。例如，当视窗被其他视窗遮盖住，且服务器没有维护后备存放区时。此时服务器会产生一个Expose事件，以通知客户端重绘视窗已消失的部分。 事件的范例：当在视窗上按下按键时，会产生事件给客户端（取决于视窗的事件掩码，客户端可以改变事件掩码）。大部分的事件只会在客户端预先表示关心时才会传送。因为客户端可能只需要关心某类型的事件。例如，客户端可能会关心关于键盘的事件，但却不关心关于鼠标的事件。即使在客户端并未明确请求的情况下，某几类事件也会不断的传送给客户端。 事件的范例 客户端可以设置视窗的属性值（attribute），以指明想要接收哪些事件。例如，当视窗的内容已销毁时，为重绘其内容，客户端就必须接收Expose事件，以通知视窗需要再次重绘。客户端要能接收到Expose事件，就要预先指明它所关心的事件，这部分可以适当设置视窗属性值的事件掩码来完成。 不同的客户端可以请求同一视窗的事件。甚至可对同一视窗设置不同的事件掩码。例如，某个客户端可以只对视窗请求键盘事件，而另一个客户端只对视窗请求鼠标事件。这是可以的，因为服务器会为每一个客户端维护事件掩码，而且是每一个视窗都维护一份独立的事件掩码。不过偶尔也有某几类事件，只能由一个客户端选择。特别是，这类事件回报鼠标按钮的点击，且部分变化会涉及到视窗管理器。 xev程式显示视窗所涉及到的事件。xev-idWID可对识别子为WID的视窗要求所有可能的事件，并将其输出。 七：颜色 在协议层次里，颜色使用32位元无负号整数来表示，称为像素值。以下因素会影响颜色的显示： 1.色彩深度 2.色彩映射（colormap），即含有红、绿、蓝强度值的表。 3. 视觉类型（visualtype），指明表如何用来表示颜色。 在最简单的情况下，色彩映射是一种每一项都含有RGB三值的表。像素值x所表示的颜色，就包含在表中第x项。如果客户端可以改变色彩映射的内容，那这种表示法就以伪彩色（PseudoColor）视觉分类（visualclass）来标识。视觉分类中的静态色（StaticColor）与伪彩色类似，只不过客户端不能修改色彩映射的内容。 在此总计有六种可能的视觉分类，每一种都使用不同的方式来表示 RGB像素值。PseudoColor和StaticColor即其中两种。GrayScale和StaticGray是另外的两种，其中最主要的差异是灰阶渐层的使用。 剩下的两种视觉分类和前述的差异在于，将像素值分成三个部分，并为红、绿、蓝的强度使用了三个独立的表。并根据这个表来表示颜色，如下流程将像素值转换成RGB色： 1. 将像素值视为连续的位元序列 2.将位元序列分成三个部分 3.将每一个部分视为整数、并作为索引，以在这三个独立的表中寻找到值。 这个机制需要以三个独立的表组成色彩映射，三个原色各一个表。转换以后仍是强度值的三联色。使用这个表示法的视觉分类有DirectColor和 TrueColor，其中的差异是客户端不能修改后者的色彩映射。 以上六种以像素值表示颜色的机制，都需要附加一些参数来运作。这些参数可统合为视觉类型，其包含一个视觉分类和其他参数以表示颜色。每一个服务器都有一组固定的视觉类型，每一个类型都与数值型的识别子关联。其识别子是32位元无负号整数，和资源或元素的识别子没有什么不同。 当接受来自客户端的连线时，服务器所传送的接受封包里含有区块序列，每一个区块都包含有关于某一个单一屏幕的资讯。就每一个屏幕而言，相关区块包含着其他区块的清单，每一个都涉及了屏幕所支援的色彩深度。就每一个屏幕所支缓的色度深度而言，这个清单中又包含视觉类型的清单。结果，每一个屏幕就关联著各种合适的色彩深度，而且每一个屏幕的每一个色彩深度都关联著各种合适的视觉类型。一个给定的视觉类型可用于更多的屏幕和各种不同的色彩深度。 就每一个视觉类型而言，接受封包中还包含它的识别子和它所包含的实际参数（视觉分类等），客户端存放这些资讯，因为之后就不能再请求。此外，客户端不能改变或建立新的视觉类型。建立新视窗的请求中，还包含有色彩深度和视觉类型的识别子，以此用来表示视窗的颜色。 色彩映射和控制屏幕的硬件（即绘图卡）是否使用调色盘（palette）没有关系。调色盘是一个表，也是用来表示颜色的。即使硬件并不使用调色盘，服务器也能使用色彩映射。当硬件使用调色盘时，就只能安装相当受限的少许色彩映射。更精确的说，当硬件根据色彩映射来显示颜色时，就可以说是安装了色彩映射。客户端可请求服务器安装一个色彩映射。不过需要将另一个色彩映射解除安装：其影响是视窗如果使用了解除安装的色彩映射，就不能显示正确的颜色，而出现怪异颜色的画面。这个问题可以用标准色彩映射来解决，标准色彩映射是像素值和颜色之间关联恒定的色彩映射。由于有这一性质，就可让不同的应用程式使用标准色彩映射。 色彩映射的建立由ICCCM协定管理。标准色彩映射由ICCCM和Xlib规格管理。 八：元素 元素（Atoms）是用来表示字串的 32位元整数。本协议的设计者之所以引入元素，是为了以简短、大小恒定的方式表示字串：由于字串可以是任意的长度，而元素总是32位元整数。某些封包可能会多次传送相同的字串，元素的简短性可以削减指令所使用的封包长度，进而增进网络的使用效率。大小恒定的元素有利于大小恒为32字节的事件：大小恒定的封包可以包含元素，却不能包含过长的字串。 更严谨的说，元素是存放在服务器上的字串的识别子，相当于资源的识别子（视窗、图形映射等），但仍有两个不同点。首先，元素的识别子是由服务器选择的，而非客户端。换句话说，当客户端请求建立一个新的元素时，其仅仅传送字串给服务器存放，而非字串的识别子；元素的识别子是由服务器选择，并回传给客户端作为回应。其次，资源和元素之间的重大差异是，元素并未与客户端相连系。元素一经建立，就能一直存留至服务器结束或重置（此非资源的默认行为）。 元素是识别子，所以也是独一无二的。不过元素和资源的识别子可以相一致。与元素关联的字串称作元素名。元素的名称一经建立就不能再更改，而且不能有两个相同名称的元素。故一般以元素的内容作为元素的名称：“元素ABCD”意谓著，或更精确的说，“这个元素关联的字串是ABCD”或“元素的名称是 ABCD”。客户端可以请求建立新的元素，且可请求指定字串的元素（识别子）。某些元素已预先定义（由服务器以特定的识别子和字串所建立）。 元素运用于多个目的，主要与连接到同一服务器的不同客户端之间有关。特别是，元素用于与视窗属性的关联，以下详述。 所有存在于服务器上的元素列表，可使用xlsatoms程式输出。尤其这个程式可以元素的名称（元素所关联的字串）列出每一个元素（识别子是一串数字）。 九：属性 每一个视窗都有一组预先定义的属性值（Attribute）和属性（Property），并存放在服务器上，客户端可以适当的请求方式取存。属性值是有关视窗方面的资料，如视窗的大小、位置、背景色等等。属性则是附属于视窗上的资料片断。与属性值相反，属性在XWindow核心协议的层次中并没有其他含意。客户端可在视窗的属性中存放属性值资料。 属性是以名称、类型和值来描述，属性相当于指令式编程语言的变量，应用程式可以指定名称、类型和值来建立新的属性。属性和视窗关联：两个相同名称的属性可存在于两个不同的视窗，且可具有不同的类型和值。 属性的名称、类型和值皆为字串；更精确的说就是元素，客户端可借由识别字，以存取存放在服务器上的字串。客户端应用程式可以元素的识别子（含有属性的名称）存取特定的属性。 属性大多用于客户端之间的通讯。例如，名称为WM_NAME（属性名称就是元素所关联的字串"WM_NAME"）的属性，是用来存放视窗的名称；视窗管理器通常会读取这个属性，并在视窗顶部显示名称。 某些客户端之间的通讯也使用了根视窗的属性。例如，根据freedesktop视窗管理器规格视窗管理器应该在根视窗的 _NET_ACTIVE_WINDOW属性名，存放目前有效（active）视窗的识别子。X资源所含有的程式参数，同样也是存放在根视窗的属性里；借由这个方式，即使分别执行在不同电脑上，所有客户端仍可存取到那些参数。 xprop程式可输出指定视窗的属性，xprop-root则可输出根视窗每一个属性的名称、类型和值。 十：映射 在X Window系统中，键盘上的每一个物理按键都关联有8～255之间的号码，这些号码就称作键码（keycode）。一个键码仅仅标识一个按键，而非特定的字符或功能键（如“PageUp”）。字符或功能键则由键符来标识。键码仅仅取决于实际按下的按键，键符则可取决于按下的Shift键或其他的修饰键。 当按下或放开按键时，服务器会传送KeyPress或KeyRelease的事件类型给适当的客户端。这些事件包含： 按下按键所产生的键码。 修饰键（Shift、Control等）和鼠标按键当下的状态。 键码如何转换成键符 因此服务器传送键码和修饰状态，而无须尝试将其转成特定的字符，这部份的转换工作由客户端自己的协定来完成。例如，客户端可能接收到一个事件，而这个事件表示已按下“a”键，且Shift修饰键也已按下，客户端（不是服务器）就会把这个事件关联为“A”。 客户端完成键码至键符的转换以后，表示其关联的表就由服务器来维护，并将表集中存放在所有客户端都存取得到的地方。客户端只需请求映射，并使用它对键码和其修饰键域解码成键符。客户端也可以任意改变此一映射。 当按下修饰键时，就会改变另一个按键的解码。常见的修饰键有Shift键：平常会产生小写字母“a”的a键和Shift键一起按下时，就会产生一个大写字母“A”。其他常见的修饰键还有“Control”、“Alt”和“Meta”。 X服务器最多可用八个修饰键，不过每个修饰键可关联一个以上的按键。例如，很多键盘有两个“Shift”键（一左一右）。按下这两颗按键时，会产生两个不同的键码，不过X服务器会把那两者都关联到“Shift”修饰键。 X服务器为八个修饰键维护一份可以认出修饰键的键码清单。举个例子，如果清单中的第一个修饰键（“Shift”修饰键）包含键码0x37，然后有某个按键会产生键码0x37，X服务器就认为那个按键是Shift键。 修饰键映射的清单由X服务器维护，也可以让所有的客户端修改。例如，客户端可以请求将“F1键”加到“Shift”修饰键的清单中。从此，这颗按键的效果就如同Shift键一样，不过F1仍会产生本身的键码。结果，F1仍做它以前所做的（例如，按下F1时，会开启说明视窗），不过又和Shift一样（在文字编辑器里，按下“a”和F1，就会打出“A”）。 X服务器也为鼠标按键维护并使用修饰键映射，不过只能改变顺序。其最大的用处就是为左撇子调换左右两边的按键。 xmodmap程式可以显示并改变按键、修饰键和鼠标按键的映射。 十一：截取 截取（grab）即所有键盘或鼠标的事件，都传送到单一客户端上。客户端可以请求键盘、鼠标或两者的截取：如果服务器履行此一请求，所有键盘和鼠标的事件，都会传送到截取中客户端，直到解除截取为止。此时，其他的客户端将接收不到这些事件。 请求截取时，客户端会指定一个截取视窗：所有事件都会传送到截取中客户端，彷佛和截取视窗相关。不过其他的客户端接收不到事件，即使是在截取视窗中进行选取。在此有两种截取： X Window核心协议主动式 立即进行截取。 被动式 只在按下预先指定的按键（或鼠标按键）时才会进行截取，并在放开时结束。 如果光标或键盘是被冻结的话，其所产生的事件将会在伫列上被拦截。如果是可截取的话，其事件会转运给截取的客户端，而不是原本可接收到事件的视窗。光标事件可借由事件掩码加以排除、抛弃。客户端可截取键盘、光标或两者。截取请求中也可包含用来冻结键盘或鼠标的请求。截取和冻截的不同处在于，截取改变事件的接收者，而冻结只是完全停止递送。当装置冻结时，它所产生的事件会存放在伫列中，并在结束冻结时照常递送。 对于光标事件来说，额外的参数会影响到事件的递送：事件掩码指定要递送或抛弃哪些类型的事件。 截取请求中还包含一组字段，字段用来在还没建立截取之前，就指明传送给截取中客户端的事件将要发生什么。更精确的说，客户端可请求它们照常传送或进行截取。这两种情况和它们所表现出来的有所不同。例如，在第一个视窗上正常接收键盘事件的客户端，可能会透过第二个视窗来请求截取键盘。事件将会正常传送给第一个视窗，而未必重新导向给截取视窗，这取决于截取请求里所下的参数。 客户端也可请求截取整个服务器。在这种情况下，服务器将不会处理任何请求，除了来自截取中客户端的请求以外。 十二：Xlib 和其他的客户端程式库 主条目：Xlib 大部分的客户端程式借由Xlib客户端程式库与服务器交流。特别是客户端大多使用Xaw、Motif、GTK+、Qt之类使用到Xlib的程式库，方便和服务器互动。Xlib有以下作用： 1. Xlib使客户端的回应和事件同步化： 1.1 Xlib函式会传送请求区块，直到得到合理的回应。换句话说，不使用Xlib的XWindow客户端可传送请求给服务器，并在等待回复的期间，先做其他的事。不过使用Xlib的客户端只能呼叫Xlib函式来传送请求，并等待回复。借此阻断客户端额外的动作（除非客户端在呼叫Xlib函式之前，就执行另一个新执行绪）。 1.2 当服务器传送的事件不同步时，Xlib会把客户端接收到的事件存放在伫列里，客户端程式只能以明确呼叫X11程式库函式的方式来存取。换句话说，如果在等待事件时，会让客户端强制阻断或忙碌等待。 2. Xlib不会立即传送请求给服务器，而是先存放在伫列中，这部分称为输出缓冲；输出缓冲里的请求会在以下情况真正传送出去： 2.1 程式以程式库所提供的函式，如XFlush，明确要求。 2.2 程式所呼叫的函式，涉及服务器的回应，如XGetWindowAttributes。 2.3 程式要求在事件伫列中的一个事件（例如，呼叫XNextEvent）和呼叫区块（例如，XNextEvent区块，如果伫列是空的）。 高阶程式库，如Xt（Xaw和Motif所使用的），让客户端程式指定与事件关联的返回函式。程式库维护轮询事件伫列，并在必要时呼叫适当的函式；某些事件是在Xt内部处理，如需要重绘的视窗。 低阶程式库，如XCB，提供协议不同步存取，容许较佳的延迟隐藏。 最后综述： X Window的运行基于一种客户/服务器（Client/Server）模式，它由X Server、X Clients和通信通道3个部分组成，X Server和X Clients通过X协议在网络上通信完成应用任务。 X Server是控制输入输出的程序，它和底层硬件直接通信控制实际的显示器、鼠标及键盘的软件，它只在接收X Client程序的请求后完成建立窗口和绘制图形等工作。 X Client是基于X Server的客户程序，作为使用系统的视窗功能的程序，它请求X Server在指定的窗口执行各种操作。它不负责显示，只是给X Server发送一个请求，由服务器完成操作。 X 协议是X Server和X Client之间沟通的语言，Xlib库封装了可完成这种通信功能的API，可以使用这些API开发X Client程序。X Window运行分层如下图所示： X Window运行分层 其中最底层的是X Server，其上层是X网络协议，该层使远程运行X Window成为可能。再上层是称为“Xlib”的底层函数接口，它介于网络和基础系统与较高层的程序之间，应用程序的实现通过调用这一层的函数实现。最顶层是管理窗口的窗口管理器，即WM（Window Manager），如AfterStep、Blackbox、Enlightenment、ctwm、ftwm、sawfish、twm和Window Maker等，这些管理器中的每一个都提供了一个不同的界面。另外，KDE和GNOME桌面环境（Desktop Environments）都有自己的视窗管理器与桌面集成，每一个视窗管理器也有一个不同的配置机制。 X Window的客户机/服务器模式有如下的优点。 （1）客户程序可以在远程计算机上执行计算任务，而使用的X服务器仅负责复杂的图形显示，从而充分发挥X服务器在显示上的优势。 （2）只有X服务器与硬件打交道，所有的客户程序都与硬件无关，从而很容易在不同的平台上移植。 （3）使用不同的视窗管理器会使得X Window的外观看起来截然不同。 　　Gnome 和 KDE 是什么？ Gnome 和 KDE 是“桌面系统”，一种很多程序和函数库的集合。它们的设计目的是提供一致的方便的操作方式来满足普通用户的需要。它们不但包含窗口管理器，还有很多实用程序和应用程序，比如配置程序，工具条，编辑器，绘图工具…… 其实 Gnome 可以和很多窗口管理器合作，在历史上，Gnome 使用过的窗口管理器包括 englightenment, sawmill, sawfish, metacity。KDE 的窗口管理器叫做kwin。 zz：http://hanyu.iciba.com /wiki/4397.shtml zz：http://hi.baidu.com/bihailan/blog/item /1f08fde79280f524b8382025.html