DirectFB自帶有兩個窗口管理器：default和unique，可以在配置文件中用wm=xxx來選擇用哪一個作為當前的窗口管理器。

兩個窗口管理器的功能都很簡單，與桌面環(huán)境流行的窗口管理器幾乎沒有可比性。尤其是前者，提供的功能更是簡陋，僅僅是管理一下窗口棧而已。后者雖然簡陋，但其架構設計還算不錯，很容易在上面擴展自己需要的功能。

什么是窗口管理器呢？根據(jù)EWMH的要求，窗口管理器的基本功能有以下這些：

模態(tài)窗口(Modality)。一般用來實現(xiàn)模態(tài)對話框，所謂模態(tài)對話框，是具有這樣特性的對話框，除非你把它關掉，否則無法切換回到它的父窗口上。

大桌面(Large Desktop)。顯示器的大小是有限的，比如顯示器的分辨率為1024x768，那么傳統(tǒng)的桌面只能這么大一點。窗口管理器可以實現(xiàn)一個邏輯上的大桌面，較顯示器的物理分辨率，擁有更大的顯示范圍。當然你在某個時刻只能看到桌面的一部分，這部分也稱為viewport，通過變換viewport可以看到桌面的其它區(qū)域。

固定窗口(Sticky windows)。固定窗口要求窗口的位置被固定到顯示器的物理位置， viewport的變換對它的位置都沒有影響。

虛擬桌面(Virtual Desktops)。同時打開的窗口太多時，可以把這些窗口分成不同的組，同一時刻只顯示其中一組的窗口，每一組窗口是一個虛擬桌面。

任務條(Taskbars)、分頁器(Pagers) 。顯示當前所有的打開的窗口，并且可以在這些窗口之間切換。

窗口棧序(Z-Order) 。是窗口之間的上下關系。

保留區(qū)域（reserve space）。讓某個窗口獨占某塊靠邊的區(qū)域，比如任務條，一般都獨占桌面下面的一長條區(qū)域。

窗口狀態(tài)(Window State) 。窗口有大化、小化、全屏等的狀態(tài)，這些由窗口管理器負責管理。當然，上層應用也可以調用窗口管理器提供的函數(shù)，來改變窗口的狀態(tài)。

窗口裝飾。在unix下，GUI的慣例是，窗口的標題和四周的邊框，都稱為裝飾，這些裝飾的顯示是由窗口管理器負責的。這樣的好處時，應用程序無須做任何修改，僅通過配置窗口管理器，可以得到風格各異的顯示效果。

窗口協(xié)議。這主要用于實現(xiàn)窗口僵死狀態(tài)檢測，窗口之間的同步處理等功能。

對于嵌入式系統(tǒng)來說，并不要求實現(xiàn)桌面環(huán)境上的一些花梢的功能。unique的實現(xiàn)雖然簡單，也可以滿足基本需求，更重要的是它提供了較好的擴展機制。

DirectFB采用模塊化設計，它并不依賴于某種具體的窗口管理器，只要具體的窗口管理器實現(xiàn)接口CoreWMFuncs中定義的函數(shù)，可以掛到DirectFB中運行。

Reactor在DirectFB中無處不在，要理解DirectFB的架構一定要理解reactor模式才行。不過，這里的reactor與POSA中講解的reactor類似，但并不完全相同，它更類似于signal機制，如果你理解glib中的signal或者boost中的signal機制，理解reactor并不難。DirectFB中reactor大的優(yōu)點在于它是跨進程的，通過fusion內核模塊中轉，在一個進程中觸發(fā)的事件可以方便的中轉到另外一個進程。

Unqiue的源代碼在wm/unique目錄下，下面我們以輸入事件流把它們貫穿起來分析一下：

在DirectFB中，每一種輸入設備，都有一個線程掛在上面，只要輸入設備有事件上報，該線程通過reactor把事件轉發(fā)給相應的reactor處理函數(shù)。窗口管理在初始時(unique_wm_module_init)，調用dfb_input_add_global把_unique_device_listener設置為事件處理函數(shù)。

在_unique_device_listener中，并沒有對事件直接處理，而又把它轉給相應的UniqueDeviceClass對象，實現(xiàn)UniqueDeviceClass接口的有keyboard、pointer、wheel三種，每一種都有一個實例。

在這里，UniqueDeviceClass作為一個中間層，是否是多此一舉呢？開始我也這樣認為，過好長一段時間后，我才明白這樣做是有道理的。原因是從不同設備讀到的事件格式并不統(tǒng)一，比如有的坐標，有的是相對坐標，鍵值映射關系也不一致。這個中間層可以把這些事件轉換成統(tǒng)一的格式，上層無需要再關系這些底層細節(jié)。

把事件轉換之后，然后通過reactor分發(fā)出去，到_unique_input_switch_device_listener函數(shù)里。_unique_input_switch_device_listener里面通過當前的上下文以及事件的內容，決定誰是該事件的目標。

這里有兩點比較有趣。

第一是StretRegion。StretRegion是一塊區(qū)域，StretRegion與窗口的關系又是什么樣的呢？這種關系很很簡單，一般的窗口（帶裝飾的窗口）有十個StretRegion組成，它們分別是四邊、四角、窗口客戶區(qū)以及這九個StretRegion的父StretRegion（也稱為frame）。

對于鍵盤事件，一般是焦點窗口的客戶區(qū)收到事件，如果是筆點事件，則由筆點的位置決定是哪個StretRegion收到事件。

第二是決定了目標StretRegion之后，并不是直接把事件投遞給這個StretRegion，而是調用StretRegion的GetInput函數(shù)，獲取一個input_channel的對象。這似乎也是多此一舉，實則不然，窗口的四邊、四角、窗口客戶區(qū)九個區(qū)域是完全獨立的，它不知道也不應該知道其它八的存在，另外這個九個區(qū)域的地位也不是等同的，有的要自己處理事件，有的不用，只有每個StretRegion自己才知道，所以由GetInput去決定把事件給誰。

事件經(jīng)過input_channel之后，輪到_unique_window_input_channel_listener函數(shù)處理了。這時，事件才真正被投遞到相應的窗口，之后事情與窗口管理器無關了。

對Z-Order的管理，實際上比較簡單，無非是調整窗口在棧的位置，所謂棧其實并不是真正的棧，只是一個雙向鏈表，大家都習慣的稱為棧罷了。

Unique實現(xiàn)了簡單的裝飾功能，相關代碼在foo_update里（并沒有用到decoration.c/.h）。它的圖片數(shù)據(jù)在data目錄中。Unique的裝飾功能大的缺陷是，沒有根據(jù)不同類型的窗口實現(xiàn)不同的裝飾。