\\\     /
                                  \\\   /
                                   \\\ /
                                    \//\
                                    / \\\
                                   /   \\\
                                  /     \\\

                      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ň