Hlavní (kořenový) protokol X Window System ( angl. X Window System core protocol ) je formát pro interakci systému X Window , síťového okenního systému pro rastrové video terminály . X Window je založeno na modelu klient-server , tj. jeden server spravuje všechny I/O, jako jsou obrazovky, klávesnice a myš, všechny aplikace fungují jako klienti a komunikují s uživatelem a ostatními klienty prostřednictvím serveru. Tuto interakci zajišťuje kořenový protokol. Existují také další protokoly, které jsou jak „doplňky“ nad kořenem, tak zcela nezávislé.
Kořenový protokol X Window System poskytuje pouze 4 typy datových paketů zasílaných asynchronně přes síť: požadavky, odpovědi, události a chybové zprávy. Požadavky jsou odesílány klientem na server, aby provedl nějakou akci (například vytvoření nového okna) a/nebo řekl serveru, aby poslal zpět některá data. Odezva serveru zajišťuje předání těchto dat klientovi. Události jsou odesílány serverem, aby informovaly své klienty o aktivitě uživatele nebo jiné aktivitě na straně serveru, o kterou má konkrétní klient zájem. Chybová hlášení zasílá server svému klientovi v případě chyb při zpracování klientských požadavků. Požadavky mohou generovat odpovědi, události nebo chybové zprávy. Protokol nestanoví povinnou sekvenci pro přenos paketů po síti. Existují rozšíření kořenového protokolu s vlastními požadavky, odpověďmi, událostmi nebo chybovými zprávami.
System X se objevil na MIT v roce 1984 (aktuální verze X11 je v září 1987). Jeho vývojáři Bob Shifler a Jim Geths se při jeho vývoji řídili pravidlem, že kořenový protokol by měl zakládat „mechanismus, nikoli soubor pravidel politiky“. V důsledku toho kořenový protokol nespecifikuje interakci mezi klienty a mezi klientem a uživatelem. Podléhají dalším specifikacím [1] , jako je ICCCM a Freedesktop.org a obvykle se provádějí automaticky pomocí předdefinované sady widgetů .
Komunikace mezi serverem a klienty probíhá výměnou paketů přes kanál. Spojení naváže klient (jak se klient spouští, není v protokolu definováno). Kromě toho klient odešle první paket obsahující endianness, který má být použit, a informace o verzi protokolu, stejně jako typ autentizace očekávané klientem, pro použití serverem. Server odpoví odesláním zpět paketu potvrzujícího nebo zamítajícího připojení nebo požadavkem na další ověření. Je-li připojení potvrzeno, je paket obsahující data odeslán klientovi pro použití v následné interakci se serverem.
Po navázání spojení se pro výměnu mezi klientem a serverem přes kanál používají čtyři typy paketů:
Požadavky a odpovědi jsou odesílány v paketech různé délky, zatímco pakety událostí a chyb mají pevnou délku 32 bajtů .
To, co se běžně označuje jako okno ve většině grafických uživatelských rozhraní v systému X Window, se nazývá okno nejvyšší úrovně. Termín okno se také používá k označení oken, která leží v jiném okně, tedy podokně z nadřazeného okna. Grafické prvky jako tlačítka, nabídky, ikony atd. lze implementovat pomocí podokna.
Klient může požádat o vytvoření okna. Přesněji řečeno, může požádat o vytvoření podokna v rámci existujícího okna. V důsledku toho jsou okna vytvořená klienty uspořádána do stromu (hierarchie). Kořenem tohoto stromu je kořenové okno, což je speciální okno vytvořené automaticky při spuštění serveru. Všechna ostatní okna jsou přímo nebo nepřímo podokny kořenového okna. Okna nejvyšší úrovně jsou přímá podokna kořenového okna. Je zřejmé, že kořenové okno má stejnou velikost jako obrazovka (ačkoli může být větší, v takovém případě může uživatel viditelnou oblast přesunout) a je základem všech ostatních oken.
Není vždy zaručeno, že obsah okna bude v průběhu času zachován. Zejména může být obsah okna zničen, když se okno přesune, změní jeho velikost, zakryje se jinými okny a obecně se stane zcela nebo částečně neviditelným. Konkrétně se obsah ztratí, pokud X server nepodporuje ukládání obsahu okna do pomocné paměti. Klient může požadovat uložení obsahu okna do pomocné paměti, ale server to nevyžaduje. Klienti tedy nemohou předpokládat, že podpora pomocné paměti existuje. Pokud má viditelná část okna nedefinovaný obsah, událost odešle klientovi zprávu, že by měl být obsah okna vykreslen znovu.
Každé okno má přidruženou sadu atributů, jako je geometrie okna (velikost a poloha), obrázky na pozadí, zda je požadováno jeho uložení do pomocné paměti atd. Protokol obsahuje požadavky na klienta na kontrolu a změnu atributů okna. .
Windows mohou být InputOutput nebo InputOnly. Okna prvního druhu lze zobrazit na obrazovce a použít pro kreslení. Druhý typ oken se na obrazovce nezobrazuje, slouží pouze k příjmu vstupu.
Ozdobné okraje a záhlaví (možná včetně tlačítek), které jsou běžně vidět kolem oken, vytváří správce oken , nikoli klient, který okno vytváří. Správce oken také spravuje vstup související s těmito prvky, jako je změna velikosti okna, když uživatel klikne a přetáhne rám okna. Klienti obvykle pracují v okně, jsou vytvářeni bez zohlednění změn provedených správcem oken. Zvažte také správce oken, kteří nahrazují společné kořenové nadřazené okno pro okna nejvyšší úrovně. Většina správců oken to nyní dělá. Z pohledu základního protokolu je správce oken klientem stejně jako ostatní aplikace.
Informace o okně lze získat spuštěním programu xwininfo. Při spuštění z příkazového řádku s argumentem --tree tento program zobrazí strom podoken z okna spolu s jejich identifikátory a geometrickými daty.
Bitmapový obrázek je uložen v paměti serveru, nezobrazuje se na obrazovce, ale může být celý nebo částečně vykreslen v okně. Obsah okna lze uložit jako bitmapu. To umožňuje dvojité ukládání do vyrovnávací paměti. Grafické operace použitelné pro okna lze použít také pro bitmapy.
Okna a bitmapy se nazývají oblasti kreslení. Obsah kreslicích oblastí je uložen na serveru. Klient může odeslat požadavek na přenos obsahu oblasti ze serveru na klienta nebo naopak.
Klient může požadovat několik grafických operací, jako je vymazání oblasti, kopírování oblasti do jiné, kreslení bodů, čar, obdélníků a textu. Kromě vymazání lze všechny operace provádět na všech plochách výkresu.
Většina požadavků na grafické operace zahrnuje grafický kontext, datovou strukturu, která obsahuje parametry pro grafické operace. Grafický kontext zahrnuje barvu popředí, barvu pozadí, písmo textu a další nastavení. Při požadavku na grafické operace klient zahrnuje grafický kontext. Ne všechna nastavení grafického kontextu ovlivňují operaci: například písmo neovlivňuje kreslení čáry.
Základní protokol nařizuje použití písem na straně serveru. Tato písma jsou uložena jako soubory a server k nim přistupuje přímo prostřednictvím místního souborového systému nebo přes síť pomocí jiného programu nazývaného server písem. Klient si může vyžádat seznam písem dostupných na serveru, může požádat o nahrání nějakého písma na server (pokud takové písmo na serveru ještě není) nebo nahrát písmo (pokud jej nepoužívají jiní klienti) na server. Klient si může vyžádat informace o písmu (například o vzestupu písma) a prostoru, který zabírá konkrétní čára při kreslení konkrétním písmem.
Názvy písem na úrovni hlavního protokolu X Window jsou libovolné řetězce. Konvence logických písem pro X přesně specifikuje, jak by měla být písma pojmenována podle jejich atributů. Tyto konvence také určují hodnoty dalších vlastností, které mohou písma mít.
Program xlsfonts zobrazuje seznam písem uložených na serveru, zobrazuje symboly písem a umožňuje uživateli vybrat název písma pro vložení do jiného okna.
Vykreslování písem na straně serveru je nyní považováno za zastaralé a většina klientů (GTK, Qt) již vykreslování písem provádí. K vykreslení písem používají klienti knihovny Xft nebo cairo a rozšíření XRender. Specifikace základního protokolu nepopisuje vykreslování písem na straně klienta.
Všechna data o oknech, bitmapách, fontech a dalších objektech jsou uložena na serveru. Klient ukládá identifikátory (jedinečná čísla) těchto objektů a používá je jako jména při interakci se serverem. Například klient, který si přeje vytvořit okno, odešle serveru požadavek na vytvoření okna s daným ID. Identifikátor může klient použít později, např. pro vyžádání čar nakreslení na okno. Následující objekty jsou uloženy na serveru a jsou dostupné klientovi prostřednictvím digitálních identifikátorů:
Tyto objekty se nazývají zdroje. Když klient požaduje vytvoření jednoho z těchto zdrojů, uvede také jeho identifikátor . Například pro vytvoření nového okna klient zadá jak atributy okna (rodiče, šířka, výška atd.), tak identifikátor přidružený k oknu.
Identifikátory jsou 32bitová celá čísla , jejichž tři nejvýznamnější bity jsou vždy nula. Každý klient má svou vlastní sadu ID, které lze použít k vytvoření nových zdrojů. Tato sada je vydána serverem v potvrzovacím paketu (paket odeslaný klientovi k označení, že připojení bylo přijato) a je reprezentována dvěma čísly. Klienti vybírají identifikátory z této sady tak, že různé objekty mají různé identifikátory.
Jakmile je zdroj vytvořen, může klient použít jeho ID v požadavcích na server. Některé operace ovlivňují tyto prostředky (například požadavek na přesun okna), jiné požadavky na prostředky uložené na serveru (například požadavky na atributy okna).
Identifikátory jsou jedinečné nejen pro klienta, ale i pro server. Dvě okna tedy nemohou mít stejné ID, i když jsou vytvořena dvěma různými klienty. Klient může přistupovat k libovolnému objektu podle jeho identifikátoru (i k objektu jiného klienta).
Výsledkem je, že dva klienti připojení ke stejnému serveru mohou používat stejný identifikátor k odkazování na stejný zdroj. Pokud například klient vytvoří okno s ID 0x1e00021 a předá toto číslo 0x1e00021 jiné aplikaci (jakýmikoli dostupnými prostředky, jako je uložení tohoto čísla do souboru přístupného také jiným aplikacím), pak tato další aplikace může běžet na stejném okno.. Tuto funkci využívá například X Window verze programu Ghostview : tento program vytvoří podřízené okno, uloží jeho identifikátor do proměnné prostředí a zavolá Ghostscript , který vykreslí obsah PostScriptového souboru a zobrazí jej v tomto okno [8].
Prostředky jsou obvykle zničeny poté, co klient, který je vytvořil, uzavře připojení k serveru. Před ukončením spojení však může klient odeslat serveru požadavek, aby je nezničil.
Události jsou pakety odeslané serverem klientovi se zprávou, že se stalo to, co klient očekával. Událost je například odeslána, když uživatel stiskne klávesu nebo stiskne tlačítko myši. Události lze použít pro více než jen vstup: události například posílají indikaci k vytvoření nových podoken v daném okně.
Každá událost je spojena s oknem. Pokud například uživatel klikne myší, bude se událost odkazovat na okno, nad kterým byl kurzor v okamžiku kliknutí. Balíček události bude obsahovat ID tohoto okna.
Klient může požádat server o odeslání události jinému klientovi. To se používá k organizaci interakce mezi klienty. Taková událost je například generována, když klient požaduje vybraný text a je serverem odeslána klientovi, který vlastní okno s vybraným textem.
Událost Exposeje odeslána serverem, pokud byl obraz oblasti okna klienta vymazán z paměti a okno se stalo viditelným. Obraz okna je vymazán z paměti, pokud bylo okno minimalizováno, překryto jiným oknem a v jiných případech.
Většina typů událostí je klientovi zaslána pouze v případě, že o ně dříve deklaroval svůj zájem. Klienta mohou například zajímat události klávesnice, ale ne události myši. Přesto jsou některé typy akcí předávány klientům, i když si je výslovně nevyžádali.
Klient vybírá požadované typy událostí nastavením speciálního atributu okna - masky události. Chcete-li například začít kreslit obsah okna, musí klient obdržet soubor Expose. Server však tuto událost odešle pouze v případě, že klient nastavil příslušný bit v masce události okna.
Různí klienti mohou vyžadovat události ze stejného okna. Mohou dokonce nastavit různé masky událostí ve stejném okně. Jeden klient může například vyžadovat pouze události klávesnice, zatímco jiný může vyžadovat pouze události myši. Existuje však několik typů událostí, které lze doručit pouze jednomu klientovi. Konkrétně se jedná o události zpráv po kliknutí myší a některé změny související se správou oken.
xev- program, který zobrazuje události ve vztahu k oknu. Příkaz se zejména xev -id WIDdotáže na všechny možné události týkající se okna s identifikátorem WIDa vytiskne je.
Následuje příklad možné interakce mezi serverem a programem, který vytvoří okno s obrázkem černé skříňky a ukončí stisk kláves. V tomto příkladu server neodešle žádnou odpověď, protože klient odešle požadavek, který negeneruje odpovědi. Tyto dotazy mohou způsobit chyby.
Pokud okno překrývá jiné okno a znovu je nepřekrývá, za předpokladu, že záložní úložiště není spravováno, pak:
Na úrovni protokolu je barva reprezentována 32bitovým celým číslem bez znaménka nazývaným pixelvalue . Na barevné reprezentaci se podílejí následující prvky:
V nejjednodušším případě obsahuje mapa barev RGB triádu v řadě. pixelvalue xje x-tý řádek v tabulce. Pokud klient může změnit položky v mapě barev, pak je pohled identifikován s vizuální třídou PseudoColor . Vizuální třída StaticColorje podobná, ale klient nemůže měnit položky v tabulce barev.
K dispozici je celkem 6 vizuálních tříd. Každý je definován jiným způsobem reprezentace RGB triády s hodnotou pixelu. PseudoColora StaticColorprvní dva. Další dva - GrayScalea StaticGray, se liší tím, že zobrazují pouze odstíny šedé.
Zbývající dvě vizuální třídy se liší od výše uvedených v tom, že nepoužívají triádu pixelvalue, ale používají tři různé tabulky pro hodnoty intenzity červené, zelené a modré.
Podle reprezentace barev se pixelvalue převádí na RGB triádu v následujících případech:
Tento mechanismus vyžaduje, aby se mapa barev skládala ze tří samostatných tabulek, každá pro jednu ze základních barev. Výsledkem transformace jsou další tři hodnoty intenzity. Vizuální třídy používané tímto pohledem jsou: DirectColornebo TrueColor, které se liší tím, že klient může změnit mapu barev nebo ne.
Všech těchto šest mechanismů pro reprezentaci barev pomocí pixelvalue vyžaduje některé další parametry, aby fungovaly. Tyto volby jsou shromážděny ve vizuálním typu , který obsahuje vizuální třídu a ostatní volby pro reprezentaci barev. Každý server má omezený počet nainstalovaných vizuálních typů a každý typ je spojen s číselným identifikátorem. Identifikátory jsou 32bitová celá čísla bez znaménka, ale nemusí se nutně lišit od identifikátorů zdroje nebo atomu.
Po přijetí připojení od klienta obsahuje potvrzovací paket odeslaný na server sekvenci bloků, z nichž každý obsahuje informace o jedné obrazovce. Pro každou obrazovku obsahují relativní bloky seznam dalších bloků, každý relativní blok definuje barevnou hloubku podporovanou obrazovkou. Pro každou barevnou hloubku tento seznam obsahuje vizuální typy. V důsledku toho je každá obrazovka spojena s některými možnými hodnotami barevné hloubky a každá barevná hloubka každé obrazovky je spojena s možnými vizuálními typy. Tyto vizuální typy lze použít pro jiné obrazovky a různé barevné hloubky.
Pro každý typ vizuálu potvrzovací paket obsahuje oba tyto identifikátory a skutečné parametry obsahu (typ vizuálu atd.) Klient si tyto informace ukládá, protože si je nebude moci v budoucnu znovu vyžádat. Klienti navíc nemohou měnit ani vytvářet nové typy vizuálů. Požadavky na vytvoření nového okna zahrnují barevnou hloubku a identifikátor vizuálního typu pro zobrazení barev v tomto okně.
Barevné mapy se používají nezávisle na hardwaru, který ovládá obrazovku (tj. grafická karta může nebo nemusí používat paletu (tabulku barev). Servery používají barevné mapy, i když hardware nepoužívá paletu. Když hardware používá palety, lze nainstalovat omezený počet barevných map. Barevné mapy se nastavují zejména tehdy, když hardware zobrazuje konzistentní barvy. Klient může požádat server o instalaci barevné mapy. To však může vyžadovat odstranění jiné barevné mapy: důsledkem použití odstraněné barevné mapy bude obrázek s nesprávnými barvami, efekt dvojitého shluku barev nebo barvy s vysokou intenzitou. Tento problém lze vyřešit použitím standardních barevných map. Jedná se o barevné mapy s předdefinovanými asociacemi mezi hodnotami pixelů a barvami. Díky této kvalitě mohou být standardní barevné mapy využívány různými aplikacemi.
Tvorba barevných map se řídí dohodou ICCCM. Standardní barevné mapy jsou definovány specifikací ICCCM a Xlib.
Součástí systému barev X je systém správy barev X (xcms). Tento systém se objevil s X11R6 Release 5 v roce 1991. Tento systém je obsažen ve formě několika dalších funkcí Xlib, které se nacházejí v řadě funkcí, jejichž názvy začínají Xcms. Systém definuje barevná schémata nezávislá na zařízení, která již lze převést na systémy RGB závislé na zařízení. Systém obsahuje funkce Xlib Xcms* a také konvenci XDCCC (X Device Color Characterization Convention), která popisuje, jak se různé barevné systémy nezávislé na zařízení převádějí na barevné systémy RGB závislé na zařízení. Tento systém podporuje barevné systémy CIEXYZ, xyY, CIELUV a CIELAB a také TekHVC.
| Systém X Window | |
|---|---|
| Architektura |
|
| Správci oken |
|
| Rozšíření |
|
| Implementace | |
| Normy | |
| Aplikace |
|