\\\ /
\\\ /
\\\ /
\//\
/ \\\
/ \\\
/ \\\
Proč používat okna, když máme dveře?
-- Andre Fachat
Přístup programátorů k počíčové grafice se postupem času
vyvíjel. Kdysi dávno, kdy počítače ještě nebyly, se programátoři
počítačovou gafikou nezabívali. Potom, co byly vymyšleny počítače a
grafické zařízení programátoři psali grafické rutinky přímo do
programů. Později zjistili, že je lepší si napsat některé časté
funkce do knihoven. Grafické terminály potom oddělily tyto rutinky
od programů a zajistily to, aby programy mohly běžet jinde, než sedí
operátor (nebylo tedy nutné, aby uživatelé si sedali na procesor,
podpíraly nohy pamětí a kabát věšeli na sběrnici). V XeroXu si zase
všimli, že není od věci, aby grafické programy spolu spolupracovali
a udělali první okna (ne to nebyl Bill).... Programátoři na MIT
potom zkombinovali tyto okna z nejzajímavějším nápadem grafických
terminálu - tedy to, že aplikace můžou běžet vzdáleně (na jiném
počítači, než se zobrazují) a byl na světě projekt jménem X window
system (ne windows!).
Jak to už na MIT bývá zvykem (koukněte se na GNU) rozhodli se to
vyřešit opravdu velkoryse. Kladli si několik cílů:
- Aby mohlo běžet několik programů v různých oknech
- Aby bylo možné zobrazovat aplikace vzdáleně
- Maximální rychlost
- Co nejvíce využít možnosti hardware
- Aby design v nejbližších pětseti letech nezastaral a nepodléhal
různým módním trendům, nebylo nutné měnit API apod.
- Aby X byly nezávislé na použitém hardware, operačním systému,
jazyce apod. (X NEJSOU jen pro UNIX, ale i pro OS/2, Windows, DOS
apod.)
- Prosadit X jako standard.
Jak vidíte měli se co činit. Musím říct, že výsledek se jim na
svoji dobu opravdu podařil. Přesto, že projekt začal před přibližně
20 roky dodnes udržuje tempo, nijak výrazně nezastaral a dá se říct,
že stále patří k nejmodernějším programům ve své kategorii.
Uživatelé X oken mají většinu vylepšení jako první. (plastická
tlačítka, podpora 3d grafiky, dolní lišta a další originální
vymoženosti Win95 jsou pro uživatele X oken cca deset let starou
záležitostí)
20 let je pro počítače hodně, a to hlavně pro počítačovou
grafiku. Je nutné si uvědomit, že X vznikaly v době, kdy slovo
počítačová grafika znamenalo ascii-art. Přesto ale všechny
vymoženosti moderní doby jako barvičky, paleta, truecololor,
hardwarové accelerátory, 3d karty, vektorové fonty, ikonky apod.
nijak X nezaskočily a jejich podpora šla celkem jednoduše
implementovat. Já mám doma workstation z roku 1984 (v tom roce tuším
také odělali prvni XT) a dodnes na ni můžu honit xdooma a další
programy a nejsou potíže s kompatibilitou. Je pravda, že X maji i
dost problémů ale o těch až později. V X oknech bylo vymyšleno dost
zajímavých nápadů, o kterých bych chtěl hlavně napsat.
Jak to všechno v MIT udělali? Rozhodli se, že X by nemělo
aplikaci diktovat, jak má vypadat, protože právě vzhled aplikace
podléhá nejčastěji změnám. GUI přenechali knihovnám. To došlo tak
daleko, že X nedefinují ani rámeček kolem okna, ale přenechávají to
oddělenému programu jménem window manager, který může vypadat
jakkoliv. Pro komunikaci v síti navrhli X protokol, který přenáší
zprávy typu "nakresli čáru" na jednu stranu a "myš zmáčknuta" na
stranu druhou. X se tedy zkládají ze tří oddělených částí - X
serveru, což mmůže být libovolný počítač s grafickým displayem
(dokonce existují hardwarové X servery), window manager a aplikace.
Tyto části spolu komunikují po síti X protokolem (samozřejmě, že pod
rozumným OS mohou běžet na jednom počítači bez sítě).
Typická aplikace postupuje asi takto: v proměné DISPLAY si
přečte, ke kterému X serveru se má připojit, nažhaví IP spojení a
přihlásí se. X server (pokud aplikaci neodmítne) jí hned pošle haldu
informací - jaké má obrazovky (jeden X server může spravovat jich
hned několik, na jednom počítači ale může běžet také několik X
serverů), rozlišení, velikosti obrazovky v milimetrech a další.
Aplikace potom požádá X server o vytvoření okna - předá mu haldu
informací jako barvu pozadí, rozměry, jestli ukládat schovanou část
okna, (pro aplikace co neumí okno překreslit), nebo ukádat obraz pod
oknem (pro menu) apod., vybere si fonty, předá serveru různé bitmapy
ikon apod a konečne zavolá mapWindow, které okno zobrazí. To se
předá Window manageru, který určí definitivní pozici a velikost okna
a opatří ho libivým rámečkem a nadšený uživatel už může obdivovat
prázdné okno :)
Na kreslení do okna X podporuje haldu grafických primitiv. Těch
umí opravdu hodně (až příliš mnoho - to způsobuje hlavní problem X -
velikost). Rozděleno je to asi takto: ke kreslení potřebujete
drawable - to může být okno, nebo pixmap (bitmapa v paměti X serveru
- ne aplikace) a grafický context (ten určuje věci jako barvu
[rastr], clipání [do libovolně mnoho čtverců, nebo jiné pixmapy]
apod). Kreslit potom můžete téměř cokoliv - čáry (normální,
přerušované, tlusté apod.), polygony, text apod. Protokol nepřenáší
ale příkazy jako "kresli čáru" ale "kresli čáry" a tak můžte
optimálně kreslit hned několik čar najednou.
Každé drawable má přiřazen visual, coč je seznam vlastností
tohoto zařízení - jako kolik ma bitů na pixel, jestli používá paletu
apod.
Pomocí takového protokolu můžete napsat třeba hru - nakreslíte
si jednotlivé panáky do pixmap, jejich masky do černobílých pixmap
a potom při zobrazování člověk napřed nakreslí černobílou pixmapu
pomocí AND (tam kde má být sprite se obrazovka vyčerní) a potom přes
XOR vlastní bitmapku. Funguje to celkem dobře. Pokud chcete
framebuffer, nakreslíte to do pixmapy, kterou potom naráz zobrazíte
do hlavního okna. Protože contextů může být vytvořeno naráz hned
několik, na jednoho panáka potřebujete tři zprávy - nakresli přes
XOR, přes AND a zobraz bitmapu do okna. Protokol prostě postačuje i
na věci, na které rozhodně navržen nebyl.
Na kreslení grafiky v paměti aplikace slouží XImage - vytvoříte
si bitmapu u sebe, něco tam nakreslíte a potom to celé odešlete do X
serveru. To se používá třeba na iknonky apod.
Pozadí je také okno a tak je možné na něm dělat to samé co
jinde.
Navíc X podporuje cestu, jak do serveru přidávat různé
dobrovolné rozšíření - jako podporu nečtvercových oken (vypadá to
opravdu hezky, když jsou hodiny v kulatém okně :), podporu
screensaveru (aby X dalo aplikaci vědět, když uživatel dlouho nic
nedělá apod. Šikovné je napřiklad MitSHM, které umožňuje, aby X i
aplikace naráz kreslily do sdílené bitmapy (pokud běží na jednom
počítači) a tak programy jako doom můžou běžet stejně rychle jako
pod DOSem, protože se neztrácí čas přenosem grafiky přes síť.
Existují i rošíření pro double buffering, sprite, joystick, tablet a
mnoho dalších. Nejsou ale moc používaná, protože ne všechny X
servery je musí podporovat.
V X jde prostě udělat skoro všechno (včetně 3d her) a celkem
rychle (testy ukazují že třeba můj program XaoS běží pod X
rychleji než pod VESA2.0). Jsou také zadarmo a proto se X velmi
rychle prosadily a staly se jedním z mála standardů opravdových v
UNIXu.
Problém X je to, že GUI přenechali knihovnám. Navrhli sice
knihovnu Xintrisc - což je knihovna pro práci s widgety v C, na
které lze postavit objektově orientovanou GUI knihovnu (má podporu
pro standardní konfigurační sobory a další vymoženosti), ale ani ta
nediktuje žádné API. Na ní postavili knihovnu jménem Athena, která
ale měla dost ošklivý design.
A tak mnoho lidí pochopilo, že nastal jejich čas udělat nový
skvělý grafiký interface a vzniklo jich víc, než by bylo milo.
Nejznámější je Motif (to je to, odkud nová Billova okna ukradla
design, je také stavěna na Xintrisc), OpenLook (to má narozdíl od
Motifu pěkná zaoblená okénka a je psáno v C++), Qt, Gtk (něco na
styl Motifu, protože Motif není zadarmo, tentokrát v C ale bez
intrisc), jiní zase přepsali athenu, aby vypadala lépe a tak se už
nepodažilo prosadit standard. Některé z nich sice vypadají opravdu
dobře, mají i zajímavé a originální nápady, ale každá aplikace
vypadá jinak, jinak se ovládá a je v tom binec. Podobná situace
panuje mezi windowmanagery.
Navíc neexistuje zatím žádný rozumný standard pro komunikaci
mezi aplikacema (jako je OLE ve woknech). V X sice funguje clipboard
ale i ten celkem nevalně a to je skoro všechno...
Low level programování v X oknech je také velmi komplikované. Je
to díky tomu, že se autoři snažili dosáhnout maximálního využití
hardwaru, který se během času měnil. Třeba na začátku byly pouze
černobíle bitmapy ale některé měly jako 0 černou jiné zase bílou,
aby se X nemuselo zdržovat převodem bitmap na jednom z těch
hardwarů, aplikace prostě dostane informaci, který pixel je bílý a
který černý a podle toho musí generovat buď normální nebo inverzní
bitmapy. Později přibily barvy - nejprve čtyřbarevné a
šesnáctibarevné displaye s pevně definovanou paletou a tak vznikl
fixedcolor, kde si každý může přečíst paletu. Potom přibyla paleta a
tak do X přidali komplikovanou podporu palety - není to jako jinde,
kde se paleta řekne napevno a ditheruje se, ale zde je jedna sdílená
paleta a navíc každé okno si může definovat svoji lokální paletu
(pokud to je třeba - potom po najetí myši do okna obrazovka
přeblikne a změní se paleta). Ve sdílené paletě každá aplikace může
alokovat barvu - prostě řekne: já potřebuju barvu tu a tu. X potom
projde paletu a jeslti už tam ta barva je, řekne index aplikaci,
pokud tam není, vezme jednu z volných indexů v paletě a obsadí ho
tou barvou. Aplikace na konci zase barvu uvolní pro jinou aplikaci.
To funguje dobře, pokud se ale nenajde program, který pro sebe
nahamouní všechny barvičky. V tom případě musí mít všechny programy
podporu pro to, co dělat v případě, že alokace selže (vytvořit
lokální colormap, běžet černobíle, nebo najít nejbližší barvu v
existující paletě). Navíc může barva být alokována read write -
další aplikace ji už nebude moci naalokovat a tak je možné ji měnit,
aniž by blikalo něco, co nemá. Pak se dostal ke slovu truecolor, ten
ale může být 15, 16, 24, nebo 32bitový, little edian, nebo big edian
apod. A tak aplikace dostane pouze informaci o tom, kolik je bitů na
pixel a masku pro červenou, modrou a zelenou. Navíc existují
černobílé displaye a další. Vůbec se už nebudu zmiňovat o
DirectColloru.... Všechno jde sice celkem snadno ovladat přes
XAllocColor, která buďto zaalokuje barvu, nebo najde nejbližší, ale
už je vám asi jasné, že barvičky pod X nejsou legrace. Aplikace
stejně musí počítat se všemi těmito možnostmi. Protože X alloccolor
občas může třeba na černobíle bitmapě vybrat bílé písmo na bílém
pozadí apod. X nemají dithering (to si aplikace musí zařizovat sama
pomocí patternů) a tak to není až tak jednoduché.
Podobná situace je i u jiných problémů (je fakt, že u barviček
asi nejhorší) a tak low level programování pro X opravdu není snadné
ale protože není slušný standard pro nějaké high level knihovny (pro
vlastní grafiku se teď prosazuje OpenGL s podporou 3d apod a pro UI
to vypadá na Gtk) je psaní pro X opravdové umění.
Navíc podpora všech těchto služeb je složitá a vlastní X server
není jendoduchá záležitost. Spustitelný soubor je asi 2MB dlouhý a
po spuštění si uzme něco kolem 4MB, windowmanager další 2MB a tak
jsou X na počítači pod 8MB RAM úplně nepoužitelné a rozumě začínají
fungovat až na 16MB. Svoji náročností na paměť se dají srovnávat i z
WindowsNT a to je už co říct. To samozřejmě přináší spomalení a tak
se snaha o maximální rychlost vlastně nedosáhla svého cíle.
Přesto je X dost dobrý okení server (neznám žádný lepší
použitelný) a jdou v něm psát dost rychlé a hezké aplikace - viz
například doom, quake a různé programy pro Sillicony :) Myslím ale,
že by X zasloužily důkladnou revizi, třeba za cenu ztráty
kompatibility, prostě napsat něco podobného ale menšího, jenoduššího
a modernějšího.
výheň