Modules

#模块结构#

##应用程序和服务器## EGUI项目采用的是C/S结构，也就是在正常运行时有一个服务器和多个用户程序。

###服务器的职责###

• 接收来自用户程序的绘图请求
• 绘制图像到屏幕
• 接收来自键盘和鼠标的输入
• 对输入进行分析（如判断出单击、双击等），并转换成消息传递给用户程序
• 向用户程序传递控制消息（如结束运行等） 服务器需要向Framebuffer设备和键盘、鼠标设备进行读取和写入，需要足够的权限。所以服务器一般用root权限运行。

###用户程序的职责###

• 接收来自服务器的用户输入消息和控制消息
• 控制应用程序逻辑，实现面向用户的功能
• 管理界面上的控件，并将它们的绘制拆解成画点和线等服务器支持的简单步骤
• 向服务器发送绘图请求
• 处理用户输入 由于服务器只支持简单的绘图请求，控件都是实现在用户端的。 用户程序不需要太多权限，只需要与服务器通信即可，所以一般用普通用户运行。

##二进制结构## 代码上分成多个模块，这一点在code outline里面已经说了。但是对每个模块的使用还体现在另一个方面。

###Shared Objects### 每个模块编译之后都会生成一个.so文件，这类似于Windows里的.dll文件，包含一系列函数定义，它们实现的功能可以被任意的代码使用。其他代码要使用它们，只要使用包含这些函数声明的头文件，然后链接的时候与.so文件绑定即可。这些函数定义的二进制代码并不会被复制到那些使用它们的程序里，而是留在.so文件里。在运行一个程序时，系统会自动把它绑定的那些.so文件加载到内存里。 大多数现代系统都是基于这种动态链接的技术构建的，所以几乎所有的程序都有那么几个绑定的.so文件。Linux下的ldd指令可以查看可执行文件绑定的共享库，比如运行ldd /usr/bin/bc会显示如下内容：

    linux-gate.so.1 (0xb7794000)
    libreadline.so.6 => /usr/lib/libreadline.so.6 (0xb7755000)
    libc.so.6 => /usr/lib/libc.so.6 (0xb75a6000)
    libncursesw.so.5 => /usr/lib/libncursesw.so.5 (0xb754e000)
    /lib/ld-linux.so.2 (0xb7795000)

=>左边的文件名在.so之后还有.1、.6等，那是它们的版本号。右边是对应的路径。

###EGUI里的链接结构### .so文件里的代码也可能使用其他.so文件，所以它们是可以互相连接的。最后一系列的.so文件与一个含有main函数的源文件一起编译，就可以生成一个可执行文件。 EGUI在编译时一共会产生11个.so文件，其中有一些是给客户端用的，一些是给服务器用的，另一些是公用的。服务器程序需要使用的特别功能，比如绘图功能（libgraph.so）不应该被用在用户程序里，所以用户程序不会与libgraph.so进行连接。另外，client_lib、application、widget只用在客户端；server_lib、graph等只用在服务器端。 上面这些都是比较典型的，还有很多其他复杂的依赖关系。这里不多赘述，大家在编写代码时自然会慢慢知道。

##头文件结构### 每个模块要被使用，除了必要的.so文件需要链接以外，为了在代码里正确调用函数，还必须有对应的头文件。头文件里必须包含.so库文件里函数的声明。 EGUI里所有模块的头文件最终被集成到一个对外的.h文件里，放在include文件夹下。这个对外的.h文件会引用模块内其他的头文件，编译器会根据这个自动将它展开成所有函数的声明。 include文件夹下除了各个模块的头文件之外，还有一个config.h.in，这是用于配置编译的，之后在autotools里会讲到。