在本章，我們將觀察重點擺到系統控制的使用者介面，例如，系統如何顯 示有人使用它，以及包含那些結構等。

Ｘ設計的目標之一就是能支援許多不同型式的使用者介面，一般其它的視 窗系統提供特殊的交談方法，而Ｘ則提供一般性的架構，讓系統建立者 (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的應用程式介面在編譯的時 候就被決定了，如果不重新編譯便無法改變。

MIT 版的Ｘ大多數的應用程式均使用標準的工具箱和一套來自MIT 的工具 箱軟體構成要素，這造成你可以得到一致性的介面。除此之外，有些結構更提 供了定制的應用程式操作方法和設定它們的預設值。

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) 稍後再”貼”到另一個應用視窗，”性質” 在此被用到，”性質”依序編成”CUT_BUFFER0”，”CUT_BUFFER1”…等等， 所有的應用視窗便可藉此交換資料。

最後一個例子是稱為resources 的”性質”，它被用來定義應用程式的預 設值設定，在根視窗(root window) 中有一個名為RESOURSE_MANAGER的性質存 放著所有設定的名單，它會被所有的應用程式存取，用來做是否要執行任何設 定的依據。

3.3.2 在Ｘ中視窗的階層性

本節描述視窗在系統中的組織及如何建立，和對應用程式的影響。

所有在Ｘ中的視窗都可視為一個樹狀結構階層 (hierarchy)的一部份，樹 的根部便是根視窗，涵蓋了整個螢幕，應用視窗都是根視窗的子代(children)， 上層的視窗可以擁有它自己的子視窗，圖3-1 有兩個應用視窗。

┌———————————————┐ │ p34 fig 3.1 (???) │ │ │ │ 圖3-1 在螢幕上重疊的視窗 │ └———————————————┘

”paint ”程式包含了一個被當做選單用的子視窗，對每一個選擇又有一 個子視窗對應，相關的視窗樹見圖3-2 。

┌———————————————┐ │ p35 fig 3.2 │ │ │ │ 圖3-2 視窗的樹狀結構階層 │ └———————————————┘

在Ｘ的設計理念下，制造一個視窗非常容易，你可以利用視窗來控制選項 ，像選單、卷動棒(scrollbars)、控制鈕(control button)等等，即使是大量 也無妨，例如像試算表中的一個cell等。這種觀點從程式設計師的角度大於使 用者，但的確對使用者當他”定制”(customising) 特定的程式時有影響，在 本章以後的章節會再度提到。

為了允許應用程式有子視窗，Ｘ提供了大量的設備程式供client程式使用， 如此不但能達成一致性，也避免了相同的需求造成了重復的工作，例如像圖3-1 的下拉式選單，可以在應用程式中以一致子視窗完成，這個子視窗有它們自己 的選單選擇方框(pane)，和用以偵測使用者碰觸滑鼠按鈕的標準結構，如果沒 有子視窗，復雜的程式和輸入處理將無可避免。

子視窗的位置和大小并不受父視窗的限制，子視窗可大可小，可以大過父 視窗或只占父視窗的一部份，但是它會被父視窗剪裁(clipped) ，也就是說， 子視窗所有超出父視窗的部份將會消失不見。見圖3-3

┌———————————————┐ │ p36 fig 3.3 (???) │ │ │ │ 圖3-3 受父視窗限制的子視窗 │ └———————————————┘

在實際的應用上，你可以將上層的視窗定義成幾乎占住整個螢幕，就不必 擔心子視窗有些部份會看不到了。

另外一種方式就是把下拉式選單定義成為根視窗的子視窗，如此選單便可 以比應用視窗還大，如圖3-4

┌————————————————┐ │ p36 fig 3.4 (???) │ │ │ │ 圖3-4 選單比用它的應用視窗還大 │ └————————————————┘

3.3.3 Ｘ不是深植於作業系統

不像其它大多數的系統，Ｘ并非深植(embedded)於作業系統中，而只是比 使用者層次稍高而已。更精確地說，Ｘ不需要深植於系統，雖然有些制造廠商 可能是為了效率(performance) 的理由將server和作業系統結合在一起，但不 深植於作業系統的結構有下列利益：

．易於安裝和改版，或甚至去除。這種工作不需要重新啟始系統，也不會 對其它應用程式造成干擾。

．第三集團很容易支援加強它的功能。例如你的制造廠商提供的系統不夠 好，你可以向別人買更好或更快的版本。

．Ｘ不會指定作業系統，因此成為一種標準，這也是第三集團發展軟體的 原動力。

．為了發展者利益。在server上發展工作時，當程式當掉只會當掉視窗系 統，不會造成機器的損壞或作業系統核心的破壞，沒有作業系統核心碼 的程式也較易除錯。

3.4 結論

在本章中我們描述了許多Ｘ提供的使用者介面，我們介紹了你用以管理 案頭的程式 -- 視窗管理器的概念，也描述了被用來做使用者和client應用程 式間交互作用的設備程式。我們介紹了用來做client間通訊的性質結構，Ｘ視 窗的階層結構對系統的影響，最後對視窗系統不深植於作業系統的好處做一摘 要。

本章所強調的著眼點，在於針對你每天都用到的視窗系統的部份作一整體 性的概觀，了解這些將幫助你學習得更快，更能好好地運用系統。

本書第一部份 -- 系統概觀就此結束，下一個部份將告訴你如何實際使用 系統。