Okenné systémy pre UNIX

2.6.2004 Rudo Thomas

Obsah

  1. Obsah
  2. Úvod
  3. X Window System
  4. Trendy
  5. Alternatívy
  6. Záver
  7. Zdroje

Úvod

Najpoužívanejší okenný systém v UNIXe, X Window System, nedávno oslávil 20 rokov existencie. Stále viac sa však uvažuje o jeho náhrade.

Najprv popíšem slabé, ale aj silné stránky X Window Systemu (ďalej X11). Následne naznačím, ako nedostatky X11 riešiť vo všeobecnosti a veľmi v rýchlosti predstavím konkrétne riešenia v podobe niektorých z hlavných alternatívnych okenných systémov. V závere sa pokúsim odhadnúť najbližší vývoj na poli okenných systémov v UNIXe.

X Window System

X Window System prežil už viac ako 20 rokov, čo svedčí o jeho (relatívne) dobrom dizajne. V súčasnosti je aktuálna 7. revízia 11. verzie protokolu, X11R7. Ide o vyzretý, odskúšaný a stabilný systém. Má však aj svoje nedostatky, ktoré sa - ako sa niektorým zdá - nedajú riešiť inak, ako návrhom systému úplne nového. Takýmto alternatívam sa venujú ďalšie kapitoly.

X11 je architektúrou typu klient/server. Server má prístup k hardvéru a je zodpovedný za samotný výstup na zariadenie, ktorým je zvyčajne grafická karta. Komunikácia s klientami prebieha cez sokety, čím je umožnená sieťová transparentnosť, čiže beh aplikácii na ľubovoľnom stroji, ktorý sa dá so serverom cez sieť prepojiť. Samotné komunikačné správy môžu byť principiálne buď požiadavky klienta smerom na server, alebo udalosti smerom opačným. Klient žiada server napríklad o vytvorenie okna, či nakreslenie nejakého prvku; server informuje klienta, okrem iného, o stlačení klávesu, pohybe myši, ale aj o tom, že okno, ktoré prislúcha danému klientovi bolo odkryté a treba ho prekresliť (Expose event).

Ďalším faktorom, ktorý X11 zaručil široké a dlhodobé nasadenie je jeho rozšíriteľnosť. Protokol je navrhnutý tak, že sa dá prakticky ľubovoľne rozšíriť, avšak bez porušenia spätnej kompatibility. Aplikácie napísané pred 20 rokmi by mali bez najmenších problémov bežať na moderných implementáciach X servera.

V neposlednom rade je tiež významná modularita X servera. V skutočnosti ide o implementačnú záležitosť najznámejšej z implementácii, XFree86, ktorá za rozšírenie vďačí určite aj vhodnej licencii. V ostatnej stabilnej verzii (4.4) je však licenčné ujednanie výrazne zmenené, čo podnietilo vznik "nových" implementácii, ktoré sú založené na kóde XFree86 z času tesne pred touto zmenou.

X11 má však aj výrazné problémy. Z programátorského hľadiska je najväčším príliš nízka úroveň rozhrania (API) ako aj jeho značná komplikovanosť. Klientská knižnica Xlib síce ponúka štandardný toolkit (súbor ovládacích prvkov), ktorý však už dlho nie je dostatočne abstraktný. Výsledkom je skutočnosť, že aplikácie pre "čisté" X sa prakticky vôbec nevyvýjajú. Pochopiteľne existujú kvalitné nástroje pre vývoj grafických užívateľských rozhraní (GUI) pre X11, čo ale vedie k ďalším tažkostiam...

Asi najväčšou prekážkou masového nasadenia X11 je nekonzistencia výsledného prostredia, ktorá vyplýva z toho, že sa na vývoj programov pre X11 využívajú viaceré toolkity. Užívateľ totiž očakáva jednoliatosť či už vizuálnu, ale aj napr. možnosť používať rovnaké klávesové skratky vo všetkých programoch. Existuje niekoľko celých prostredí (KDE, GNOME, ...), ktoré sú založené na jednom konkrétnom toolkite, čo im zaručuje istú úroveň konzistencie. Táto spravidla končí v momente, keď je užívateľ nútený spustiť program, ktorého obdoba v danom prostredí neexistuje. V poslednej dobe sa síce vyvýjajú témy (skiny) pre jednotlivé toolkity, ktoré zaručia ak nie zhodný, tak aspoň veľmi podobný vzhľad rozhraní, ale prakticky je možné pokryť len pomerne malú časť programov.

Častokrát sa X Window Systemu vytýka, že keďže bol navrhnutý na úplne inak dimenzované stroje, je pre súčasný hardvér zastaralý. Sčasti je to pravda. Vždy síce existuje možnosť naprogramovať rozšírenie, ktoré by danú oblasť pokrilo, ale ako sa ukazuje, nebýva to vždy jednoduché. Môže sa totiž stať, že sa bude musieť porušiť spätná kompatibita, prípadne sa nešikovne navrhnuté rozšírenia budú navzájom nechcene ovplyvňovať, či dokonca vylučovať. Príkladom na problém so spätnou kompatibilitou je rozširenie XRANDR, ktoré slúži (v konečnom dôsledku) na zmenu veľkosti root okna. V X ale "platí", že veľkosť tohoto okna je pevná, nemenná. Aplikácie, ktoré sa na túto skutočnosť spoliehajú môžu v extrémnych prípadoch spadnúť; v lepšom prípade bude chyba len vo výstupe. Najznámejšou ukážkou nedobre sa ovplyvňujúcich rozšírení je dvojica Xinerama a XV.

Ďalším tradičným dôsledkom vysokého veku je nedostatočná možnosť konfigurácie už bežiaceho servera. Tentokrát však nejde o vek samotného protokolu, ale o vek implementácie XFree86, ktorá bola navrhnutá v čase, keď bolo vybavenie počítača prakticky nemenné: stačilo server nakonfigurovať pred samotným štartom. V súčasnosti sa pomerne dynamicky môžu meniť nielen zariadenia vstupné, ale aj výstupné (monitory).

Posledný závažný nedostatok je pomerne špecifický, nemusí sa totiž týkať bežného uživateľa na bežnom systéme. X11 stavia na jednoduchosti servera, ktorý ponúka len základné služby. Všetka "logika" je sústredená v klientoch, čo má za následok už spomínanú nutnosť používať toolkity na vyššej úrovni ako je X protokol. Okrem toho tento prístup kladie vysoké nároky na komunikačný kanál medzi serverom a klientami. Kritická je nielen latencia, ale aj objem prenášaných dát. Bežného užívateľa, ktorý pravdepodobne spúšta programy (X klientov) na tom istom stroji, na ktorom beží server, tento problém na prvý pohľad trápiť nemusí. Treba si však uvedomiť, že aj prechod dát medzi adresnými priestormi (z klienta na server) je svojim spôsobom pomalá operácia.

Trendy

Nečakane veľká skupina z horeuvedených problémov sa dá riešiť presunom niektorých úloh klienta na stranu servera. Jednou zo základných je kreslenie obsahu okien. Pri každom odkrytí nejakej časti okna obdrží klient od X servera udalosť Expose, na ktorú prakticky vždy reaguje tak, že prekreslí danú oblasť príslušným regiónom už naplneného buffra, ktorý je spravidla uložený na serveri. Principiálne jednoduchým vylepšením je vynechanie zbytočnej komunkácie klient - server - klient. V taktomto prípade musí mať server k dispozícii obsah okna, čo už aj tak býva skutočnosťou. Výsledkom je rýchlejšia odozva, pričom v porovnaní s "modernou" X aplikáciou by sa nespotrebovala žiadna pamäť naviac (neuvažujeme naivnú implementáciu). (X11 podobnú funkcionalitu síce umožňuje, ale v praxi podpora chýba na strane serveru.)

Nápad s ponechaním prekresľovania v kompetencii servera sa dá rozšíriť na oveľa väčšiu množinu udalostí. Napríklad informácie o každom pohybe myši môžu značne zaťažiť prenosovú linku, pričom klient by si vystačil s oznámením "tlačidlo bolo odkliknuté". Tým sa dostávame k menej triviálnej zmene, ktorou je implementácia prvkov rozhrania (toolkitu) na strane servera. Takýto návrh môže mať výrazný dopad nielen na objem dát prenášaných medzi klientom a serverom, ale hlavne na komplikovanosť API. Programátorovi samotnej aplikácie (GUI), ktorý už nad X11 používa toolkit vyššej úrovne, tento posun asi žiadnu zmenu neprinesie; naopak, autorom knižníc by mal výrazne pomôcť. Opäť to však vyžaduje dostatočne pružný dizajn.

Najdôležitejšími dôsledkami umiestnenia prvkov GUI na server by malo byť výrazné odľahčenie prenosového kanálu, a hlavne toľko žiadané zjednotenie vzhľadu a ovládania programov. Pochopiteľne bude najťažšie navrhnúť potrebne široké spektrum elementov GUI. Ak by totiž nebol k dispozícii bežne používaný ovládací prvok, ľahko sa môže stať, že si každá knižnica napíše vlastný a konzistecia ostane znova len ideálom.

Znakom dobre navrhnutej grafickej aplikácie býva striktne oddelené rozhranie od samotnej algoritmickej časti. Do istej miery takéto oddelenie vyžadujú už aj niektoré zo súčasných toolkitov. Presun rozhrania na server by tomuto smerovaniu mohol výrazne pomôcť, čím by sa určite zdvihla úroveň dizajnu programov s GUI. Systém Fresco doviedol spomínanú separáciu do extrému: vždy rozlišuje hodnotu (model) a ovládací prvok (prípadne prvky), ktorý túto hodnotu mení.

Ďalšie trendy, ktoré sa objavujú medzi hlavnými cieľmi nástupcov X11, sú na prvý pohľad čisto implementačnými záležitosťami. Z pohľadu bežného užívateľa ale bývajú nepostrádateľné. Prvou z nich je konfigurácia za behu. Pri návrhu X servera XFree86 s ňou jednoducho nepočítali a neexistuje ani dnes. Skoro všetky detaily o vstupných a výstupných zariadeniach musia byť v konfiguračnom súbore uvedené ešte pred štartom. Na "modernom" stroji sa však obnovovacia frekvencia monitora, či počet tlačidiel na myši môžu zmeniť, na čo by mal byť okenný systém pripravený. Tiež by bolo dobré, ak by sa dala za behu vymeniť nejaká časť servera, napríklad ovládač grafickej karty. XFree86 je síce modulárny, toto ale neumožňuje.

S príchodom nových, väčších aj menších výstupných zariadení súvisia aj snahy opustiť pixelové miery. Cieľom niektorých systémov býva jednotný vzhľad toho istého grafického rozhrania. Bez ohľadu na to, či beži na obrovskom monitore s vyským rozlíšením alebo na LCD displeji, ktorého rozmery sú pár centimetrov. Avšak aj bežný užívateľ sa môže stretnúť s problémami podobného druhu: napríklad pri výmene monitora. X server pozná hustotu jeho bodov, toolkit teda prispôsobí veľkosť písma, ale veľkosť ovládacích prvkov (ktorá je rovnako dôležitá!) zostane častokrát bezo zmeny. Príčinou je práve to, že ich vykresľovanie býva založené na rozmeroch v jednotkách pixelov. Ak by sa používali skutočné miery (povedzme milimetre), v spojení s vektorovým modelom kreslenia by sa dalo popísaným nedostatkom predísť. Nevznikali by ani problémy pri dynamickej zmene zobrazovacieho rozlíšenia (ktoré je nevyhnutným dôsledkom zmeny veľkosti root okna - "plochy"). Súčasné aplikácie naň spravidla vôbec nereagujú - písmo a ovládacie prvky ostávajú priveľké, resp. primalé.

V neposlednom rade je nutné vytvoriť infraštruktúru na dôsledné využívanie hardvéru. Jeho rôzne pokročilé vlastnosti sa síce v X11 dajú s pomocou mnohých rozšírení použiť, avšak častokrát takéto rozšírenia celkom nezapadajú do pôvodných ideí X11 (prípadne nezapadajú do seba navzájom, ako už bolo napísané). Jednou z takýchto pomerne nových schopností je napríklad 3D akcelerácia.

Alternatívy

Z viacerých vynárajúcich sa okenných systémov som vybral nasledovné štyri. V skratke zhrniem, aké problémy X11 sa snažia riešiť a ako v tom sú úspešné.

freedesktop.org

Združenie freedesktop.org (FDo) si kladie za cieľ vylepšovať X Window System. V skutočnosti teda nejde o alternatívnu architektúru. FDo zastrešuje viaceré projekty, ktoré súvisia s vylepšovaním X11, predovšetkým však navrhuje rozšírenia, ktoré implementuje vo vlastnom serveri a klientskej knižnici. Oboje je založené na XFree86 pred spomínanou licenčnou zmenou.

Najzaujímavejší prínos FDo je v oblasti priesvitných okien. Ide o rozšírenia XDAMAGE, XFIXES a XComposite, pomocou ktorých je možné vykresľovať obsahy okien do samostatných buffrov, ktoré následne dostane k spracovaniu určený klient (compositing manager). Ten smie s bufframi ľubovoľne nakladať, napríklad ich môže preložiť cez seba, čím vzniká efekt presvitných okien. Pôvodné XFree86 takéto efekty neumožňuje, aj keď sa k nim dá trošku priblížiť; nikdy však nejde o skutočnú priehľadnosť - zmeny obsahu spodných okien nevidno.

Y Window System

Y Window System sa snaží byť, ako už jeho názov naznačuje, logickým následníkom X11. Ide o nový systém s vlastným protokolom. Ovládacie prvky (widgety) sú implementované na strane servera. Každé top-level okno má svoj vlastný buffer, čím sa dajú dosiahnuť podobné efekty ako s rozšíreniami od FDo. Zachovaná je sieťová transparentnosť. Cieľom je podpora súčasných schopností hardvéru a tiež rozšíriteľnosť, vrátane výmen implementácií za behu (napríklad výmena ovládačov za novšie verzie).

Projekt vznikol ako absolventská práca a momentálne je v ranných štádiách vývoja. Dá sa mu vyčítať napríklad to, že používa pixelové miery. Pomerne minimalistická je aj podpora vstupných zariadení. O podpore výstupných nemôže byť ani reči, zatiaľ systém funguje len nad už nejakým existujúcim prostredím (napr. X11, či Windows).

PicoGUI

PicoGUI je okenný systém určený predovšetkým pre zariadenia akými sú mobilné telefóny, či osobný digitálni asistenti (PDA). Cieľom sú preto nízke nároky na pamäť, či výkon stroja. Na serveri je implementované "všetko, čo sa na server dá presunúť", aspoň podľa vyjadrenia autorov. Opäť sú to widgety ale tiež uživateľské témy (skiny) vo forme jednoduchého interpretovaného jazyka. Výsledkom je konzistentné a nastaviteľné prostredie, a tiež nízky objem toku dát medzi klientami a serverom.

Pri programovaní pre PicoGUI je nutné oddeliť dáta a vzhľad aplikácie, na čo slúži layout engine. Miery v ňom nie sú závislé na rozlíšení výsledného zariadenia, avšak opäť sa nepočíta s tým, že by sa mohlo v priebehu behu servera zmeniť.

Fresco

Fresco (pôvodne Berlin) nie je založený na tradičných prístupoch k okenným systémom. Je úplne iný, čo možno bráni záujmu vývojárov. Systém ako taký sa pod rôznymi menami vyvýja už viac ako 10 rokov, pričom autori deklarujú, že pamätali na všetky možné použitia, vrátene tých, ktoré ešte len vzniknú.

Okrem "tradičných" vylepšení, akými sú ovládacie prvky implementované v serveri, či konfigurovateľnosť, pridáva Fresco podporu všemožných vstupných zariadení (rukavica, "3D guľa"). Zaujímavá je možnosť použiť na výstup napríklad tlačiaren.

Na komunikáciu vrámci servera ako aj medzi klientmi a serverom sa používa CORBA, čo má za následok pomerne nízky výkon v porovnaní s inými systémami. Autori Fresca však tvrdia, že používajú všetky rozsiahle možnosti CORBY a o zmene v tomto smere neuvažujú. Ďalším faktorom, ktorý výrazne spomaľuje beh je aritmetika s pohyblivou desatinnou čiarkou. Tento nedostatok v sučasnom stave zabraňuje použitiu Fresca na mobilných zariadeniach.

Ukážka grafu scényVýsledok na výstupeUkážka grafu scény.

Najvýraznejšou prevratnou myšlienkou Fresca je homogénny graf scény (scene graph). Na obrázku vpravo je ukážka časti takéhoto grafu spolu s možným usporiadaním prvkov (uzlov) na výstupe. Scene graph je vlastne pokračovaním bežne používaného prístupu, kde okná obsahujú panely, tie obsahujú povedzme tlačidlo, ktorého syn - obrázok sa na ňom nakoniec zobrazí. Homogénnosťou sa myslí možnosť ľubovoľný uzol pripojiť na ľubovoľné miesto v strome. Vkladanie celých rozhraní do iných aplikácií (KParts v KDE, OLE vo Windows) je potom hračkou: stačí pripojiť okno vkladanej aplikácie do stromu nadradenej.

V skutočnosti ale nejde o strom, ale o necyklický oriantovaný graf (DAG), pretože často používané podstromy sa dajú zdieľať (aj medzi klientami). Príkladom je už spomínané tlačidlo spolu s obrázkom zelenej fajky a text "OK". Táto trojica sa bude používať asi v každej aplikácii. V každej však bude pravdepodobne stlačenie tlačidla znamenať inú akciu. Práve tento problém riešia kontrolery. Ide o neviditeľné uzly v grafe scény, ktoré majú za úlohu odchytávať vstupy od užívateľa (nepatrí sem vstup z klávesnice, pre ktorý sa používa fokus). Pri kliknutí myši sa prechádza DAG scény zhora nadol a udalosť sa odovzdá prvému kontroleru, ktorý pokrýva dané miesto. Spracovanie akcie sa teda nastaví v kontroleri, pričom ovládací prvok (celý podstrom) pod ním, je zdieľaný. Dôležitá je tiež skutočnosť, že kontrolery sú umiestnené na serveri, takže väčšina takýchto udalostí server vôbec neopustí. Návrhári Fresca tvrdia, že tento fakt pomáha výkonu celého systému, pretože v takýchto prípadoch ide o komunikáciu (cez CORBU) vrámci jedného procesu, ktorá je relatívne rýchla.

Dialóg na výber farbyDialóg na výber farbyDialóg na výber farby spolu s príslušnou schémou.

Vo Frescu sa dôsledne oddeľujú dáta od ovládacích prvkov. Tento princíp sa tu označuje skratkou MVC (model, view, controller). Model predstavuje samotnú hodnotu, ktorú užívateľ zadáva; controler je ovládací prvok, ktorým ju mení a view je "pohľad" na daný model. Zvyčajne býva controler zároveň pohľadom - zmena modelu sa na ňom takisto prejaví. Tradičnou ukážkou je dialóg na výber farby. Modelom je trojica farebných zložiek R, G, B. Prvým pohľadom je stvorec, ktorý mení farbu na základe zmien týchto troch čísel. Ďalšie pohľady sú zároveň ovládacími prvkami: jedna trojica posúvadiel zobrazuje a mení priamo hodnoty R, G, B; druhá zobrazuje tie isté hodnoty v inom farebnom priestore (H, S, V). Zmena jednich hodnôt má za následok zmenu druhých, ako aj farby štvorca. Viď obrázok vpravo.

Poslednou dôležitou súčasťou fungovania Fresca je systém súradníc. Používajú sa trojdimenzionálne skutočné rozmery (metre), všetky v desatinných číslach. Zvláštne sú riešené posuny, či otočenia jednotlivých prvkov: dekorátory obsahujú matice 4x4, ktorými je možné prvky ľubovoľne posunúť, zväčšiť, zmenšiť, alebo otočiť. Okrem lineárnych transformácií je možné pomocou dekorátorov meniť farby, či typy písma.

Záver

X Window System pomaly starne. Existujú snahy rôznymi rozšíreniami ho udržat aktuálnym, objavujú sa aj nové systémy. Väčšinou sú však v skorých fázach návrhu, či vývoja a čo sa týka podpory hardvéru prípadne stability, X11 konkurenciu pod UNIXom nemá.

Osobne sy myslím, že najperspektívnejšie vyzerá Fresco, avšak ak bude chcieť uspieť, bude musieť od niektoých ideálov ustúpiť. Naproti tomu Y Window System má podľa môjho názoru veľmi ďaleko k modernému okennému systému. Predovšetkým kvôli používaniu pixelových mier. Avšak možno práve jeho jednoduchosť mu prinesie viac vývojárov. Na skutočnú náhradu X11 si však budeme musieť ešte pár rokov počkať.

Zdroje