X Window研究笔记(3)
3.客户/服务器架构
C／S架构是X Window最基本的架构，X Window的主体包括作为服务器运行的X Server，和中间的传输协议X Protocol，和客户封装X Protocol的函数库Xlib。应用程序通过Xlib把参数打包成X Protocol的格式，通过socket把请求发送给X Server，X Server执行请求之后再把返回值从原路返回给应用程序。
与传统的C／S架构不同的是，X Server并不是单纯的接受请求然后响应请求，它还可以主动主报事件，这通常是输入设备产生的事件。当然为了避免不必要的事件传输的开销，客户端可以决定接受哪些事件，过滤掉哪些事件。
X Window作为C／S 架构来设计，其理由是很充分的：
串行化共享资源。窗口资源是整个系统共享的，多个应用程序都要操作这些共享资源。为了有效的管理这些资源，至少要满足三点要求才行，其一是这些资源要在全局共享的，其二是要求对这些资源串行化访问，其三是要求输入设备等事件要能主动上报给应用程序，这些要求都正是C/S模型所擅长的。
远程显示。客户端在一台机器上运行，而服务器在另一个台机器上运行，这在VNC和RemoteDesktop之类的技术出现之前，这种特性为远程管理提供了非常方便的手段。客户端在远程机器上运行，而服务器XServer在本地远行，这就可以让远程的程序显示到本地机上。当然，这与传统的客户/服务器的物理位置正好反过来了。
语言与无关性。这又是C／S模型的另外一个好处，Unix下的编程语言可谓百花其放，X Window不可能为某单一语言而设计。而对于C/S模型，只要服务器端和客户端共享同样的X Protocol，两者完全可以用不同的语言开发。
从理论上说，客户端是可以不依赖于任何其它库，直接打包所有请求参数，解包所有的响应数据，就可以开发出基于X Window的应用程序。然而，这些打包解包操作比较繁琐，容易出错，也没有必要每个人都这样去做，Xlib封装了所有这些操作，简化了X程序的开发工作。由于大多数的toolkit都是Ｃ/C++写的，所以Xlib采用了Ｃ语言开发。
毫无疑问，基于Xlib可以写出在X Window上运行的GUI程序。在前面提到的X Window提供的服务中，我们可以看出，X Window提供的是非常底层的服务，就窗口而言，X Window根本不知道按钮、菜单、单选框、复选框、列表框、甚至不知道窗口管理器的存在，它唯一知道的就是窗口，这些都是非常低级的操作。
为了简化X应用程序的开发，不同组织开发了众多的 X toolkit，在这些toolkit中，都实现了一些常用的组件，以及一些公共函数。X Window的发布包带了好几种toolkit。X Window的规范中并没有规定GUI程序看起来是什么样子的，结果不同的组织开发出来的X toolkit百花齐放，形成不同的视感(look and feel)，
现在可以用一种toolkit表现不同的视感了，用来模拟其它toolkit，让来自不同阵营的用户都感到舒服。这造就了大多数toolkit都能做到，让描述风格的配置文件独立于应用程序，这是一个非常有意义的进步。
GTK+和QT是目前最流行的X tool kit，GTK＋用C开发的，QT是用C＋＋开发的，从功能、风格和易用性来看，两者各有千秋，难分伯仲。
窗口管理程序的功能比较特殊，其实它不过是一个普通X Window的客户端应用程序，后面我们会对它作比较详细的介绍。
(待续)
