X Window系統的協議和架構

視窗可能的放置情形：1 是根視窗，與整個螢幕對應；2 和 3 是頂層視窗；4 和 5 是 2 的子視窗。超出父視窗的部分不會顯示出來。

在 X Window 系統以及各種圖形化使用者界面中，視窗即為一個頂層視窗。視窗也用來指視窗內部的視窗，這類視窗是父視窗的子視窗。圖形化元件，如按鈕、選單、圖示等等，都是使用視窗來實現的。

任何視窗都只能是父視窗之下的子視窗，使視窗以樹狀的階層結構組織起來，階層結構最根部的視窗便稱為根視窗，而根視窗是由伺服器自動建立的。頂層視窗即直接隸屬於根視窗的子視窗。根視窗即整個螢幕畫面，且其他視窗都在根視窗之下。

所有關於視窗的資料、字體等等，皆存放在伺服器上。客戶端知道那些物件的識別子，和伺服器互動時，物件以整數為名稱。例如，當客戶端希望建立一個視窗時，便指定一個識別子，並請求伺服器建立一個視窗。伺服器會建立一個視窗，並與指定的識別子關聯。稍後客戶端可使用這個識別子進行請求，例如在視窗上畫上一個字串。

識別子在伺服器上是獨一無二的，在多個客戶端之間也不例外。例如，即使是由兩個不同客戶端所建立的視窗，也不會同時具有相同的識別子。即使某個物件不是由自己的客戶端所建立的，只要指定相對應的識別子，就可存取另一個客戶端所建立的物件。

每一個視窗都有一組預先定義的屬性值（Attributes）和屬性（Properties），並存放在伺服器上，客戶端可以適當的請求方式取存。屬性值是有關視窗方面的資料，如大小、位置、背景色等等。屬性則是附屬於視窗上的資料片斷。與屬性值相反，屬性在 X Window 核心協議的層次中並沒有其他含意。客戶端可在視窗的屬性中存放屬性值資料。

屬性以名稱、類型和值來描述，屬性相當於指令式程式語言的變數，應用程式可以指定名稱、類型和值來建立新的屬性。屬性和視窗連繫：兩個相同名稱的屬性可存在於兩個不同的視窗，且可具有不同的類型和值。

屬性大多用於客戶端之間的通訊。例如，名稱為 WM_NAME 的屬性，用來存放視窗的名稱；視窗管理器通常會讀取這個屬性，並在視窗頂部顯示名稱。

視窗的屬性可以 xprop 程式顯示。xprop -root 更可顯示根視窗的屬性，包括 X資源（程式參數）。

事件是由伺服器傳送到客戶端用以通訊的封包，傳送一些客戶端可能感興趣的事物。客戶端可以請求伺服器傳送事件給另一個客戶端；這部分用於客戶端之間的通訊。例如，當客戶端請求目前所選取的文字，就會傳送事件給客戶端，以處理目前所持有的選取內容。

在某些情況下，視窗的內容可能會被銷毀（例如當視窗隱蔽時）。當再度觀看被銷毀的區域時，伺服器會產生一個 Expose（顯露）事件，用以通知客戶端重繪視窗已消失的部分。

其他事件是用來通知鍵盤或滑鼠輸入的客戶端、建立新視窗等等。

某些類型的事件會不斷傳送給客戶端，但大多數的事件只在客戶端預先表示關心時才會傳送。因為客戶端可能只需要關心某類型的事件。例如，客戶端可能會關心關於鍵盤的事件，但卻不關心關於滑鼠的事件。

對於 X Window 系統處理色彩的方式，有時使用者會感到迷惑，且 X Window 支援有史以來各種不同的模式。現今大多數的應用程式皆使用真實色（TrueColor）（24 位元色彩，紅、綠、藍各有 8 位元），不過比較舊或特殊的應用程式，可能會要求使用其他的色彩模式。許多商業用的專業應用程式使用偽彩色（PseudoColor）。

目前的 X11 協議在大多數的圖形運算中，是使用一個 32 位元無負號整數來表示一個顏色，稱為像素值。當轉移到原色的飽和度時，對每一個色彩元素使用 16 位元整數。便有如下的色彩表示，但實際裝置未必能全部支援。

• 直接色（DirectColor）：像素值分為紅、綠、藍子域，每一個子域索引一份獨立的色彩映射，可改變色彩映射的內容。
  • 真實色（TrueColor）：與直接色大致相同，但色彩映射的內容是由硬體預先定義，不可改變。通常每個紅、綠、藍色彩映射提供一個（接近）線性斜度的飽和度。
• 灰階（GrayScale）：像素值索引一份色彩映射，且無色彩飽和度（黑白）。可改變色彩映射的內容。
  • 靜態灰階（StaticGray）：與灰階大致相同，但色彩映射的內容是由硬體預先定義，不可改變。
• 偽彩色（PseudoColor）（Chunky）：像素值索引一份色彩飽和度方面的色彩映射。可改變色彩映射的內容。
  • 靜態色（StaticColor）：與偽彩色大致相同，但色彩映射的內容是由硬體預先定義，不可改變。

選取、剪下緩衝區和拖曳機制在 X Window 系統中，是給使用者從某個視窗傳遞資料給另一個視窗。選取、剪下緩衝區通常用於，使用者在視窗中選取文字和其他資料，並在另一個視窗中貼上。拖曳用於，使用者在視窗中選取某些東西，然後對選取區按住按鈕，並拖曳到另一個視窗。

由於兩個視窗可能由兩個不同的應用程式所持有，資料傳遞需要兩個不同的客戶端連接相同的 X 伺服器才能互動。X Window 核心協議包含明確選擇交換的請求和事件類型，不過傳遞的完成，主要是由一般的客戶端對客戶端事件傳送，和未指明選擇傳送的視窗屬性。

客戶端之間傳送的資料可以是不同的類型：通常是文字，不過也可以是圖形、數字、物件的列表等等。

選取和拖曳是主動機制：在視窗中選取文字以後，客戶端所處理的視窗必須主動支援相關的協定，才能傳送資料到需要它的應用程式。相反的，剪下緩衝區則是被動機制：當使用者選取文字時，其內容會傳送到剪下緩衝區，即使應用程式所處理的視窗已結束並銷毀視窗，緩衝區的內容仍會保留下來。

視窗管理器是用來控管視窗整體的外觀，以及其他圖形化使用者界面的要素。在不同的安裝中，X Window 系統會有不同的外觀，主要是因為使用不同的視窗管理器，或是不同的視窗管理器配置。

視窗管理器維護視窗的位置、周圍加上裝飾性的邊框、處理圖示、處理滑鼠對視窗外表的點擊（在「幕後」）、處理按鍵（例如按下 ALT-F4 時，將視窗縮小成圖示）等等。

沒有視窗管理器的 X Window：在根視窗上沒有裝飾性的畫面、沒有圖示、沒有彈出式選單。

從 X 伺服器的角度來看，視窗管理器和其他的客戶端並沒有什麼不同。起始位置和視窗周圍的裝飾性邊框，是由視窗管理器使用如下請求處理的：

1. 應用程式可以請求伺服器不要滿足特定視窗的子視窗映射（顯示）要求，並把事件傳送過來。
2. 應用程式可以請求改變視窗的親屬關係。

視窗管理器使用第一個請求，攔截所有映射頂層視窗（根視窗的子視窗）的請求。每當另一個應用程式請求映射頂層視窗，伺服器不會去做，反而傳送事件給視窗管理器。大部分的視窗管理器會改變視窗的親屬關係：建立更大的頂層視窗（稱作框架視窗），並改變原視窗的親屬關係為自己的子視窗；相當於在框架視窗內部放置原視窗。框架視窗（而不是在原視窗上）多出來的空間，是用來裝飾視窗周圍的框架（「邊框」和「標題列」）。

視窗管理器管理滑鼠在框架視窗上的點擊。例如，當使用者在邊框或標題列上點擊並按住時，便允許改變大小或移動視窗。

視窗管理器也負責處理圖示和圖形元件的顯示關係。圖示並不存在於 X Window 核心協議的層次上，那些是由視窗管理器實作的。例如，當視窗「圖示化」時，視窗管理器 FVWM 取消映射那個視窗，使其不可見，並建立一個圖示名稱的視窗，且圖示的圖像可能和那個視窗有關。圖示的意義和處理完全由視窗管理器來決定：某些視窗管理器，如 wm2，根本不實現圖示功能。

概略地說，在一個特定時間中，期間的狀態就是「桌面的狀態」：一組視窗及其當下的內容。更精確地說，就是一系列應用程式管理的這些視窗和資訊，其允許應用程式在需要時還原所管理視窗的情況。X 期間管理器便是一個保存並還原期間狀態的程式。

使用期間管理器最明顯的作用，便是從一個互動期間登出，當再次登入時，有可能在相同的狀態下恰好發現相同的視窗。關於這部分的運作，在登出時，期間管理器程式儲存執行中應用程式的名稱，並在登入時再次啟動它們。並按照應用程式狀態的次序來還原（需要還原視窗的內容），應用程式必須能夠保存這些執行狀態，並在再次啟動時，能夠根據期間管理器的請求來讀回這些狀態。

X Window 系統含有一個預設的期間管理器，稱作 xsm。特定的桌面系統中也已開發了其他的期間管理器：例如，ksmserver 是 KDE 預設的期間管理器。