X11 under cover #1: Co to vlastne X11 je?

Na rozdiel od inych dnes beznych operacnych systemov (Windows, OS X), samotny Unix, Linux, ani dalsie fajty vstavanym grafickym okienkoidnym systemom nedisponuju, ale pre kreslenie okienok pouzivaju X Window server, ktory je vo svojej podstate len velmi primitivnou sietovou aplikaciou schopnou zobrazovat okna, rozne na seba nastackovane a trackovat polohu mysieho kurzora.

Tento serial vznikne (mozno) na zaklade mojho badania po vnutornostiach X servera, ktore som zapocal v dosledku prace na bakalarskej praci, ktorej cielom je vytvorit graficke rozhranie pre embedded zariadenia.

Trocha postavim serial hore hlavou, pretoze nebudem zacinat historiou X11, ale prejdem rovno k veci a na zaklade odozvy sa rozhodnem, ci budem pokracovat, alebo poslem serial k vode. Tento serial by sa mohol podla moznosti zamerat na fundamentalne principy cinnosti X11, zbezne prebehnut take veci, ako su graficke toolkity, windowmanagery, schranka, cut buffre, composite managery a podobne. Navyse prebehnem niekolko bezne existujucich extensionov a zopar veci, ktore na prvy pohlad vyzeraju komplikovane, ale daju sa realizovat pomerne jednoducho.

Co to ten X11 vlastne je?

Z pohladu uzivatela je to prostredie, ktore umoznuje vidiet a komunikovat pomocou grafickeho prostredia s grafickymi aplikaciami. Uzivatelovi to pripada tak, ako keby mu Xka kreslili pekne okna, menu, ikony, textove boxy, toolbary a podobne, pripadne vedeli vykuzlit prekrasny applet na pracovnej ploche, alebo efekty v docku.

Z pohladu programatorskeho je X11 sietovym serverom, ktory komunikuje pomocou sietoveho protokolu podobne, ako napriklad HTTP s klientmi. Tu treba podotknut, ze sice z uzivatelskeho hladiska to vyzera, ze v pripade X11 je uloha klienta a servera obratena, pretoze uzivatel obvykle sedi tam, kde bezi X server, ale z programatorskeho hladiska sa nic nemeni. Server je tam, kde su poskytovane zdroje, pricom v pripade X11 je poskytovanym zdrojom obrazovka, klavesnica a mys.

Z pohladu aplikacie je X server komunikacny partner, ktory sedi na opacnej strane spojenia a umoznuje aplikacii davat serveru prikazy na vytvaranie, rusenie a kreslenie do okien a prijimat od servera informacie o vzniknutych udalostiach. Tu ale nastava prvy drobny problem v terminologii medzi tym, ako chape "okno" bezny uzivatel a ako chape "okno" X server.

Totizto pre X server je oknom kazda pravouhla (!!) oblast, ktora niekde na obrazovke zacina, ma nejaky rozmer, ma urceny stacking relativne k ostatnym oknam (tzn. ktore okno prekryva ktore ine okno, obdoba z-indexu v CSS) a da sa do nej kreslit. Z toho vyplyva (a komu nevyplynulo, tak to uvediem), ze oknom je vsetko, co sa na monitore zobrazuje. Kazdy panel, menu, inputbox, tlacidlo, vsetko mozu (ale nemusia) byt okna.

Tu sa dostavame k tomu, z coho sa vlastne taka obrazovka X11 sklada. Pochopitelne sa sklada z okien. Okna su usporiadane hierarchicky tak, ze kazde okno sa nachadza v nejakom inom okne. Poloha okna sa vzdy vztahuje k tomuto materskemu oknu a vnutorne okno moze byt kludne ciastocne, alebo uplne mimo svoje materske okno. Takisto stacking (z-index) sa urcuje relativne k oknam, ktore maju to iste materske okno. Plati pravidlo, ze ak vnutorne okno svojimi rozmermi prekroci rozmery materskeho okna, cast, ktora precnieva sa nevykresli. Nadradene okno teda orezava zobrazitelnu oblast svojich podokien.

Z pravidla o tom, ze kazde okno ma svoje materske okno existuje jedna vynimka. Je nou root window, teda okno, ktore tvori samotnu pracovnu plochu. Toto okno vzdy prekryva celu oblast monitora a vsetky existujuce okna musia byt podoknom budto root window-u, alebo niektoreho jeho podokna (je mozne viacnasobne zanorenie).

Jeden by sa mozno cudoval, ako X11 povedat, ako chceme, aby vyzeralo to, co chceme, aby sa na obrazovke zobrazilo. Na rozdiel od gui32 vo Windowse, alebo Quartz rozhrania v OS X, kde staci grafickemu ovladacu povedat, aku graficku primitivu chceme a on nam ju nakresli, v X11 neexistuju ziadne graficke primitivy. Existuju len pravouhle (znova !!) okna, do ktorych si aplikacia musi vykreslit obsah, ktory chce mat zobrazeny. Okna nemaju ziaden priradeny typ, alebo chovanie. Chovanie okien na obrazovke a to, co sa z nich stane, riadi pomocou reakcii na udalosti samotna aplikacia.

Tu sa dostavame k druhej fundamentalnej sucasti X-Window a to udalostiam. Udalosti posiela X server klientovi vzdy, ked takuto udalost nieco, alebo niekto vyprovokuje a navyse ak si klient takuto udalost ziada dostat. Najprv k tomu, co provokuje posielanie udalosti. Jednym zo zdrojov udalosti (najcastejsim) je uzivatel. Dobanie do klavesnice, hybanie kurzorom, stlacanie mysitok produkuju udalosti.

Dalsim zdrojom udalosti su ale aj samotne okna. X11 je podobne, ako HTTP, nestavovy protokol. Cize samotny X server si nepamata, co bolo v okne vykreslene. Znamena to, ze ak sa do okna aplikacia nakresli obrazok, uzivatel okno zminimalizuje, aplikacia zhnije a nasledne uzivatel okno obnovi, uvidi jednofarebnu plochu.

V momente, ked sa zobrazi okno, alebo jeho cast, ktora predtym nebola viditelna (bola mimo zobrazitelnu oblast, pripadne bola prekryta inym oknom), X server zisti, ktora aplikacia je majitelom okna a posle jej tzv. ExposeEvent. Tato udalost aplikacii hovori, ze niektore (to, ktore, je v evente uvedene) jej okno potrebuje prekreslit. Aplikacia tak ucini a obsah sa zobrazi.

V clanku som viackrat dvoma vykricnikmi upozornil na to, ze X11 vie kreslit len a iba pravouhle okna, ale to bude zrejme v zjavnom rozpore s vasim moznym pozorovanim chovania niektorych okien (trebars okenna dekoracia Plastik v KDE ma zaoblene rohy okien, alebo aplikacia oclock zobrazi prekrasne kruhove hodiny). Odpoved bude prekvapiva, ale obaja mame pravdu. X protokol naozaj nema podporu pre okna ineho, nez pravouhleho tvaru, ale aplikacia napriek tomu vedia vykreslit okna ineho tvaru. Dosahuje sa toho pomocou specialneho rozsirenia protokolu, tzv. X Shape extension. Toto rozsirenie obsahuje mechanizmy, ako mozno urcit, ktore casti okna su priehladne (nie alfa kanalom, ale obycajnym transparentnym bitom: vidno / nevidno). Miesto v okne, ktore je priesvitne, sa ani nechova, ako keby oknu patrilo, teda ked uprostred okna nechate vytvorit dieru a budete do nej klikat, na klikanie budu reagovat okna, ktore je cez dieru vidno.

Druha vec, ktoru je mozne uviest na pravu mieru je to, ze X server je bezstavovy, teda si nepamata nic, co bolo vykreslene. V tradicnom X serveri takato moznost naozaj neexistuje, ale moderne X servery casto obsahuju implementovanu vlastnost tzv. backing store. Ak sa oknu nastavi flag backing store a zaroven server ma tuto funkciu implementovanu a v nastaveniach je zapnuta, server moze (ale nemusi) pri vykreslovani obsah okna ukladat do bufferu, ktory sa pouzije v pripade, ze by cast okna bola prekryta a bolo by potrebne ju zobrazit. Aj nadalej sa vsak pri pokuse o zobrazenie predtym skrytej oblasti aplikacii posle ExposeEvent.

Tato ficura sa pouziva napriklad na rychle vykreslenie pracovnej plochy do rootovskeho okna. Aplikacia pokresli rootovske okno wallpaperom a sama sa ukonci. Rootovske okno s nastavenym backing store flagom si pokreslenie zapamata, samotna aplikacia sa moze ukoncit a wallpaper bude vzdy dostupny. Pre bezne aplikacie sa to ale nepouziva, pretoze by sa jednalo o grandiozne plytvanie pamatou. Treba si uvedomit, ze okna sa casto z velkej casti prekryvaju a X server uklada backing store nekomprimovany. Teda jedno fullscrenove okno s piatimi tabmi, rozlisenim 1024x768 zaberie v najlepsom pripade priblizne 6MB v priestore X servera + dalsiu pamat v priestore aplikacie potrebnu k prekresleniu.

Dalej by mohlo byt uzitocne doplnit, ze takisto nie je nutne, aby vsetky objekty na obrazovke v skutocnosti same o sebe boli oknami v zmysle X servera. V pripade, ze to aplikacii nevyhovuje, alebo je to nepotrebne, nic nenuti aplikaciu okna vytvarat. Chova sa tak napriklad graficke prostredie Swing v Jave a zrejme aj GTK toolkit a cast windowmanagera IceWM sa takto sprava tiez. Vyhodou tohto pristupu je, ze sa omnoho lahsie realizuju graficke prvky obskurnych tvarov (ako napriklad radio gombiky, oble tlacidla a podobne). Nevyhodou je, ze cast prace X servera prebera aplikacia, kedze sama aplikacia si urcuje, kde presne bolo kliknute, co znizuje rychlost reakcie aplikacie.

Pre zaciatok by to mohlo stacit. Nabuduce, ak bude zaujem, by som dokoncil co to o eventach a nastolil tematiku grafickych toolkitov, ktore zabezpecuju, ze programatori aplikacii nemusia do podrobnosti poznat vnutornosti X11 a ze aplikacie sa daju pisat tak pekne, sexi, intuitivne a jednoducho.