DirectFB窗口管理器(unique)研究笔记

DirectFB窗口管理器(unique)研究笔记

 

DirectFB自带有两个窗口管理器：default和unique，可以在配置文件中用wm=xxx来选择用哪一个作为当前的窗口管理器。

 

两个窗口管理器的功能都很简单，与桌面环境流行的窗口管理器几乎没有可比性。尤其是前者，提供的功能更是简陋，仅仅是管理一下窗口栈而已。后者虽然简陋，但其架构设计还算不错，很容易在上面扩展自己需要的功能。

 

什么是窗口管理器呢？根据EWMH的要求，窗口管理器的基本功能有以下这些：

模态窗口(Modality)。一般用来实现模态对话框，所谓模态对话框，就是具有这样特性的对话框，除非你把它关掉，否则无法切换回到它的父窗口上。

 

大桌面(Large Desktop)。显示器的大小是有限的，比如显示器的分辨率为1024x768，那么传统的桌面就只能这么大一点。窗口管理器可以实现一个逻辑上的大桌面，较显示器的物理分辨率，拥有更大的显示范围。当然你在某个时刻只能看到桌面的一部分，这部分也称为viewport，通过变换viewport可以看到桌面的其它区域。

 

固定窗口(Sticky windows)。固定窗口要求窗口的位置被固定到显示器的物理位置， viewport的变换对它的位置都没有影响。

 

虚拟桌面(Virtual Desktops)。同时打开的窗口太多时，可以把这些窗口分成不同的组，同一时刻只显示其中一组的窗口，每一组窗口就是一个虚拟桌面。

 

任务条(Taskbars)、分页器(Pagers) 。显示当前所有的打开的窗口，并且可以在这些窗口之间切换。

 

窗口栈序(Z-Order) 。就是窗口之间的上下关系。

 

保留区域（reserve space）。让某个窗口独占某块靠边的区域，比如任务条，一般都独占桌面最下面的一长条区域。

 

窗口状态(Window State) 。窗口有最大化、最小化、全屏等的状态，这些由窗口管理器负责管理。当然，上层应用也可以调用窗口管理器提供的函数，来改变窗口的状态。

 

窗口装饰。在unix下，GUI的惯例是，窗口的标题和四周的边框，都称为装饰，这些装饰的显示是由窗口管理器负责的。这样的好处时，应用程序无须做任何修改，仅通过配置窗口管理器，就可以得到风格各异的显示效果。

 

窗口协议。这主要用于实现窗口僵死状态检测，窗口之间的同步处理等功能。

 

对于嵌入式系统来说，并不要求实现桌面环境上的一些花梢的功能。unique的实现虽然简单，也可以满足基本需求，更重要的是它提供了较好的扩展机制。

 

DirectFB采用模块化设计，它并不依赖于某种具体的窗口管理器，只要具体的窗口管理器实现接口CoreWMFuncs中定义的函数，就可以挂到DirectFB中运行。

 

Reactor在DirectFB中无处不在，要理解DirectFB的架构一定要理解reactor模式才行。不过，这里的reactor与POSA中讲解的reactor类似，但并不完全相同，它更类似于signal机制，如果你理解glib中的signal或者boost中的signal机制，理解reactor并不难。DirectFB中reactor最大的优点在于它是跨进程的，通过fusion内核模块中转，在一个进程中触发的事件可以方便的中转到另外一个进程。

 

Unqiue的源代码在wm/unique目录下，下面我们以输入事件流把它们贯穿起来分析一下：

 

在DirectFB中，每一种输入设备，都有一个线程挂在上面，只要输入设备有事件上报，该线程就通过reactor把事件转发给相应的reactor处理函数。窗口管理在初始时(unique_wm_module_init)，调用dfb_input_add_global把_unique_device_listener设置为事件处理函数。

 

在_unique_device_listener中,并没有对事件直接处理，而又把它转给相应的UniqueDeviceClass对象，实现UniqueDeviceClass接口的有keyboard、pointer、wheel三种，每一种都有一个实例。

 

在这里，UniqueDeviceClass作为一个中间层，是否是多此一举呢？开始我也这样认为，过好长一段时间后，我才明白这样做是有道理的。原因是从不同设备读到的事件格式并不统一，比如有的绝对坐标，有的是相对坐标，键值映射关系也不一致。这个中间层可以把这些事件转换成统一的格式，上层无需要再关系这些底层细节。

 

把事件转换之后，然后通过reactor分发出去，就到_unique_input_switch_device_listener函数里。_unique_input_switch_device_listener里面通过当前的上下文以及事件的内容，决定谁是该事件的目标。

 

这里有两点比较有趣。

 

第一是StretRegion。StretRegion就是一块区域，StretRegion与窗口的关系又是什么样的呢？这种关系很很简单，一般的窗口（带装饰的窗口）有十个StretRegion组成，它们分别是四边、四角、窗口客户区以及这九个StretRegion的父StretRegion（也称为frame）。

 

对于键盘事件，一般是焦点窗口的客户区收到事件，如果是笔点事件，则由笔点的位置决定是哪个StretRegion收到事件。

 

第二是决定了目标StretRegion之后，并不是直接把事件投递给这个StretRegion，而是调用StretRegion的GetInput函数，获取一个input_channel的对象。这似乎也是多此一举，实则不然，窗口的四边、四角、窗口客户区九个区域是完全独立的，它不知道也不应该知道其它八的存在，另外这个九个区域的地位也不是等同的，有的要自己处理事件，有的不用，只有每个StretRegion自己才知道，所以由GetInput去决定把事件给谁。

 

事件经过input_channel之后，就轮到_unique_window_input_channel_listener函数处理了。这时，事件才真正被投递到相应的窗口，之后事情与窗口管理器就无关了。

 

对Z-Order的管理，实际上比较简单，无非就是调整窗口在栈的位置，所谓栈其实并不是真正的栈，只是一个双向链表，大家都习惯的称为栈罢了。

 

Unique实现了简单的装饰功能，相关代码在foo_update里（并没有用到decoration.c/.h）。它的图片数据在data目录中。Unique的装饰功能最大的缺陷是，没有根据不同类型的窗口实现不同的装饰。