第３章 從使用者介面的面貌概觀Ｘ
在本章，我們將觀察重點擺到系統控制的使用者介面，例如，系統如何顯示有人使用它，以及包含那些結構等。
Ｘ設計的目標之一就是能支援許多不同型式的使用者介面，一般其它的視窗系統提供特殊的交談方法，而Ｘ則提供一般性的架構，讓系統建立者(system builder)據以建造所需的交談的風格。例如，在一個Ｘ系統中你可藉從選單中選一個動作來構建視窗，但其他對視窗的操作則全靠滑鼠來做，這種彈性允許系統開發者(developers)完全在Ｘ的基礎上產生全新的介面，也因為介面並未內建於視窗系統，因此使用者在任何時刻根據他們特別的需求可選用適當的介面。例如，對於完成一些相同的工作 -- 建立、移動、重定大小螢幕上的視窗，初學者較老手喜歡簡單的系統，而Ｘ可分別提供最適合他們的使用者界面。
使用者界面分為兩個部份：
管理界面：命令最高層的視窗如何在螢幕上建構或重建構(re-configured),也就是說，如何管理你的案頭。
應用界面：決定你和應用程式間交談的”風格”(style)： 你如何利用視窗系統的設備程式來控制應用程式及輸入資料給它。
3.1 管理界面：視窗管理器
管理界面(management interface)是系統的一部份，用以控制你螢幕上最上層的視窗（換句話說：如何重新建構你的案頭），這個部份在系統中稱之為視窗管理器(window manager)，它的功能有改變視窗的大小或位置、將視窗在堆疊 (stack)中重新安排位置、或將視窗改變成表徵圖 (icon) 等等。
在Ｘ中，視窗管理器只是另一個client程式而已，它以及系統介面的發展，和server是完全分開的，因此你可以更換它們，這類似於Unix系統中的shell命令列直譯器(interpreter) ：shell 只是一個使用者處理程式(process) ，如果你改變它，你也改變了系統的使用者介面。
3.1.1 手動的和自動的視窗管理器
有兩類的視窗管理器：手動的和自動的。手動的視窗管理器，視窗在螢幕上的位置和大小完全由使用者控制，手動的視窗管理器只是使用者用來完成工作的工具，大部份的手動視窗管理器允許應用視窗重疊。
相對的，自動的視窗管理器盡可能的由它自己來控制案頭，對於螢幕的布置盡可能讓使用者少插手。它在新建立一個視窗時自動決定視窗的大小和位置，和當視窗移動時如何重新安排其馀的視窗，通常自動的視窗管理器將螢幕分成一塊塊像磁磚一樣(tile)的區域，也就是說安排應用視窗彼此不會重疊，而且盡量占用最多的螢幕空間。
手動的視窗管理器如何工作 -- 攫取(Grabbing)
通常當你告訴手動的視窗管理器你要完成什麽動作時，是藉著使用選單或者結合了按滑鼠的按鈕和移動指標，例如，重新擺放一個視窗的位置，你可以移動指標進入視窗，按住左邊的按鈕，移動指標然後在新位置松開按鈕，視窗管理器是如何知道這些滑鼠 "事件" 的意圖的？或是換個角度，server是如何知道 "事件" 是來自應用視窗或視窗管理器？
答案是由視窗管理器告知server有哪些特定的 "事件" （碰觸按鈕等等）需要被送達，這和哪一個視窗發生的無關，這種處理稱之為攫取(Grabbing)，視窗管理器可以指定哪一個滑鼠按鈕希望被攫取，而這攫取發生在滑鼠的按鈕被按下且鍵盤上一些特定的鍵（一般稱為修飾鍵(modifer) ）也被按住（例如當CONTROL 和SHIFT 兩個鍵被按住時且滑鼠中間的按鈕被按下），當按鈕被按下時，攫取開始動作，server送出所有滑鼠的事件（包括滑鼠的移動事件）到視窗管理器直到按鈕再度松開，視窗管理器把這些 "事件" 的資料解釋成來自使用者的指令來工作。以移動視窗為例，視窗管理器在按鈕按下時被告知指標的 位置，而當按鈕松開時再度被告知，對指標的位移做一些簡單計算便可據以移動視窗。
有一件事需要使用者配合，那就是滑鼠和修飾鍵組合而成的攫取不應該為應用程式所知道，所以必需確定視窗管理器這種攫取鍵的組合不會和應用程式沖突，大多數的視窗管理器可以很容易的定義這些攫取的組合鍵，而保留給它自己使用。
3.1.2 視窗管理器額外提供的功能
視窗管理器除了具有重新建構視窗的基本功能外，也提供額外的功能改進介面的品質，通常，加入額外功能的目的是為了降低鍵盤輸入的需要，而改成盡量多用指標。
一個常見的功能是提供一個你自己可以建構的一般性選單，這樣你只要選取一個選單選項便可啟動視窗應用程式。這個啟動的命令通常包含了指示應用視窗在何處出現，大小多少，本文用什麽顏色等等。所以應用程式不需要太多的使用者輸入便能啟動。一個常見的選單用法為當你在網路上工作時，你可以定義一個選單列出所有你在網路上可用的主機，如此你便可藉著在選單上選擇主機名稱便能和任一主機建立連接。
3.1.3 視窗管理器和表徵圖
當一個視窗轉換成一個表徵圖時，表徵圖是如何來的？視窗又發生了哪些事？
表徵圖的結構非常的簡單，它只是視窗的代表圖案，當系統表徵圖化(iconify)一個應用視窗，視窗管理器只是不對應出(unmap) 這視窗（也就是說，告訴server不再顯示這個視窗到螢幕上）而把表徵圖視窗對應出來。解除表徵圖化(deiconify)則把上述的處理反過來。視窗管理器可以辦得到的原因是它沒有” 存取控制”(Access control)或許可限制來防止一個client（例如視窗管理器）不對應出其它的client的視窗，所有在同一個server上的client都可以對任意視窗或多或少做一些動作。
視窗管理器通常提供預設的表徵圖，但是client可以提供它自己的表徵圖並建議使用它，有些視窗管理器接受這個要求，有些則忽略不接受仍用自己的表徵圖，只把這個需求當作給視窗管理器的暗示(hint)。
當應用程式被表徵圖化，它的主視窗便不再被對應出來，如果視窗管理器因任何理由中斷了，則這個視窗永遠也無法再對應出來了。要避免這點，當視窗管理器表徵圖化一個視窗時，它把這個視窗加入一個名為save set的名單中，這個名單由server負責維護，如此當視窗管理器被中斷時便可重新對應出來。
3.1.4 應用程式傳遞建構資訊給視窗管理器
就如同要求顯示一個特定的表徵圖一般，應用程式也能傳遞其它的暗示或建構資訊給視窗管理器，這包括：
. 應用程式和表徵圖視窗的名稱。
. 當應用程式和表徵圖視窗被建立時，它們在螢幕上位置的資訊。
. 對視窗大小的限制（例如，client可以宣告”我所占用的視窗大小絕不可小於寬度若干x 長度若干”）。
. 對視窗重定大小的特別要求（例如，一個顯示本文的視窗，可以要求在重定大小時按特定的間隔放大或縮小，以使得視窗內的字元永遠是完整的一個，不致視窗邊框的那一行 (列) 有半個字的情況出現。）。
這種將訊息傳遞給視窗管理器的結構稱之為性質結構(property mechanism)，下一節我們會討論它。
我們可以注意到大部份重定大小或表徵圖化的事是由視窗管理器做的，這是因為它是一個公有的client，任何client均可隨意重定大小，但如果所有client都這樣做，便會造成混亂，因此要這些應用程式和平共存的原則是：不要自行重定大小，把它交給視窗管理器，也就是讓使用者去決定。
在第６章中我們會看到一個視窗管理器uwm 如何使用。
3.2 應用程式介面和工具箱
應用程式介面決定了使用者和應用程式間交談的風格，舉例來說，如何用指標選一個選項等，Ｘ不提供標准的應用程式介面，只提供基本的結構以便建造它們。
當那些具有一貫性的應用程式介面被放在一起，便叫做工具箱(toolkit)，它是基礎視窗系統軟體中最高最有效率的層次，較低層次的細節，被隱藏起來，因此簡化程式和維持介面的一貫風格變得容易執行，當使用者控制應用程式時好像有一套”虛擬文法(virtul grammer)”一般，需要注意很重要的一點是，工具箱在編譯程式的時候被指定，所以一個client的應用程式介面在編譯的時候就被決定了，如果不重新編譯便無法改變。
M99v 版的Ｘ大多數的應用程式均使用標准的工具箱和一套來自M99v 的工具箱軟體構成要素，這造成你可以得到一致性的介面。除此之外，有些結構更提供了定制的應用程式操作方法和設定它們的預設值。
3.3 其它的系統面貌
在本節中，我們討論將應用程式之間傳遞資訊所用的性質結構(property mechanism)，視窗的樹狀階層組織，和Ｘ不包含在作業系統中的優點。
3.3.1 client之間的通訊 -- ”性質”
client和server之間的通訊是藉著送出 "需求" 和接收 "事件" ，但有時client需要和其它的client傳遞資訊，例如，正常的應用程式需要告訴視窗管理器它的位置和大小，這就需要Ｘ的性質結構了。
”性質”是一小段資料的名稱，這一小段資料存在server中且關聯到一個特定的視窗，任何client均可向server查詢某一特定視窗”性質”的值。
讓我們看一個client如何把它所喜歡的表徵圖名稱傳遞給視窗管理器的范例：client把表徵圖名稱存到這個視窗的WIM_ICON_NAME ”性質”去，當視窗管理器執行表徵圖化這個應用視窗時，它會去找這個應用視窗的WIM_ICON_NAME的”性質”，而後顯示”性質”中的表徵圖名稱。
應用程式也可以和不是視窗管理器的其它的應用程式通訊，一個常見的例子是在分屬不同應用程式的視窗之間做剪貼(cut-and-paste) 操作，一段本文從一個應用程式中”切下”(cut) 稍後再”貼”到另一
