10. AZ X11 megjelenítési rendszer

  1. 10. AZ X11 megjelenítési rendszer
    1. 10.1. X11 koncepciók
      1. 1. Munkahely és képernyõ (Display and Screens)
      2. 2. Szerver-kliens modell
      3. 3: Az ablakok menedzselése: a Window Manager
    2. 10.2. X11 komponensek
    3. 10.3. Az X Window Sytem SW architektúra
    4. 10.4. Az Xprotocol elemei
    5. 10.5. Grafikus objektumok manipulálásán alapuló X-es kapcsolattartás

1987 szeptemberében az MIT (Massachusetts Institute of Technology) kibocsájtotta az X11-et: ez az X Window System v.11.

Az 1990-es évek szoftver technológiájának egyik legfontosabb eleme.

Csaknem valamennyi számítógépgyártó cég elfogadta.

Az X Window System

Az alkalmazások használhatják.

Történetéhez:

Az Athene projekt a MIT-ben és a DEC-ben indult. Más nagy cégek is támogatták.

A "guruk":

Robert Sheifler, MIT,

Jim Gettys, DEC,

Paul Asante, Strandford Univ.

Cél mint fent, legyen "public domain", - nyilvános.

Megkötések:

HW: csak raszteres grafikára (nem szigorú ez a megkötés, terjed a pixel-grafika). Raszteres eszköz: bitmapped eszköz; minden pontnak (dot) megfelel a memória valahány bitje.

OS-re nincs, minden kereskedelmi forgalomban kapható OS-re (Unix-ok, VMS, OSF1, stb.)

Hálózatra: a legelterjedtebbekre igen: TCP/IP, DECNET stb.

Sok kutatói változat után sorra jöttek a "release"-ek.

Ma már: X11R6. Nálunk is ez van már.

10.1. X11 koncepciók

1. Munkahely és képernyõ (Display and Screens)

A munkahely (display): képernyõket (screens), billentyûzetet (keyboard) és mutatót (mouse, tablet) tartalmazó, ezeket kezelni képes architektúra. Az ún. X szerver program fut rajta (10.1 ábra).

X-es munkahely (display) lehet pl.:

10.1. ábra. Egy X-es munkahely (display)

Képernyõ: maga a megjelenítõ.

Scan-line technológiájú TV monitor,

LCD képernyõ stb.

2. Szerver-kliens modell

Ismerjük a szerver-kliens modellt: a kliens szolgáltatást vár és kap a szervertõl. Üzenetváltások vannak közöttük.

Klasszikus példa:

file server - kliens,

printer szerver klienseknek,

hálózati szerver stb.

(Eddigi gondolkodásmódunkhoz tartozik: a szervert egy nagy, erõs gépnek gondoljuk, ami "távol" van, és mi a kliens elõtt ülünk. Nos, ez az X11-ben "fordított"!)

Az X11-ben a szolgáltatás: a grafikus megjelenítés és a felhasználó inputjainak kezelése!

X szerver: egy program, ami a munkahelyet (display) kezeli. A megjelenítést biztosítja. A felhasználó a szerver elött ül!

Kliensek: programok, amik akárhol futhatnak a hálózaton (rendszerint "távol"), amik nem kezelheti közvetlenül a munkahely erõforrásait.

Az X szerver feladatai:

A kliensek futhatnak a hálózat bármely csomópontján, akár ott is, ahol az X szerver fut (ekkor persze a display egy általános célú multi tasking rendszer kell legyen!)

3: Az ablakok menedzselése: a Window Manager

Az ablak (window) fogalom ismert. Több is lehet egy képernyõn (screen). Adott méretû téglalapok, jellemzõikkel...

Az X koncepcióban: nem az alkalmazások felelõsek a hozzájuk tartozó ablakok méretéért, elhelyezéséért, ikonizálásukért, mozgatásukért, hanem a Window Manager program. Az alkalmazások javaslatokat tehetnek a WM számára, de végsõ soron a WM dönt, a javaslatokat elfogadva vagy sem!

A WM is egy kliens. Xlib függvényekkel linkelték. Jogai vannak, felõssége kevés. Hol futhat? Bárhol a hálózaton, hiszen egy kliens, de legjobb, ha a display-en fut. Lehet "policy free", de lehet, hogy van ablakelrendezési politikája: stílusa. (Pl. "tiled WM": nem engedi az ablakok átfedését; "listener WM": csak a kiválasztott ablakon lehet input).

Néhény WM:

uwm - átlapolásos, régebbi X11-khez;

twm - R4-tõl, listener, a Macintoshra hasonlít;

olwm - Open Look stílusú (Sun, AT&T stb);

mwm - Motif stílusú (OSF1, IBM AIX, DEC stb).

Az X11 nem szabványosította a WM-eket. Miért? Hogy maradjon polcy free!

Alkalmazások (applications): a többi kliens. Xlib függvényekkel linkelt programok. Alkalmazkodnak a WM-ekhez, de WM nélkül is futhatnak! Nem õk mozgatják, méretezik stb. az ablakokat!

4. Események (events)

Mutató vezérelt az ablakozó rendszer: az alkalmazásoknak eseményekre kell válaszolniuk. Sokféle esemény lehet!

Példák eseményekre:

stb.

Az alkalmazások programozási stílusa: eseményvezérelt programozás (event driven programming): az alkalmazás futása közben mindíg legyen kész eseményekre reagálni. "Mellékesen" csinálhat is valamit.

A program "magja": végtelen ciklusban figyeli a beérkezõ esemény sort.

5. Kiterjeszthetõség

Erre kész kell legyen az X, mind az Xszerver, mind a kliensek oldaláról.

10.2. X11 komponensek

Public domain: csak az adathordozókért, postai költségekért, ill. az átvitelért kell fizetni. Beszerezhetõ az Interneten is.

[[alpha]]) Dokumentációk, szabványok, protokoll-leírások

User's Programmer's Guide-ok stb.

[[beta]]) X szerver programok különbözõ architektúrákhoz

Különbözõ OS-ekhez, HW-ekhez, hálózatokhoz.

Sokszor ez után nem kell menni, ma a UNIX-okhoz ezt adják.

PC-kre MS DOS alá is beszerzhetõ, akár public domain is, de a jobb minõségûekért fizetni kell.

[[gamma]]) Policy free WM-ek, különbözõ rendszerekhez

Forrás nyelven kaphatjuk, lefodíthatjuk, szerkeszthetjük. Sokszor ezek is adottak az alap UNIX-ban.

Ha nem policy free WM kell, akkor azért fizetni kell. Gyakran persze benne van az alap OS árában!

d) Egy sor alkalmazás, amik Xlib-et, Xt-t használnak csak

Pl: xclock, xcal, xhost stb.

[[epsilon]]) Run Time libraries (futásideji könyvtárak) a különbözõ rendszerekhez

Public domain könytárak:

Xlib - alacsony szintû rutingyûjtemény, de végül is minden erre épül.

Xt - toolkit, policy free widget-ek gyüjteménye. Gyorsabb a programozás a segítségével, jobb az alkalmazkodás a WM-ekhez. OOP módszerekkel épült.

include állományok a fejlesztéshez, különbözõ rendszerkhez.

10.3. Az X Window Sytem SW architektúra

A szofverarchitektúrát a 10.2. ábrán láthatjuk.

10.2. ábra. X11 szofver architektúra

10.4. Az Xprotocol elemei

4 féle üzenet csomag:

Pl:

- rajzollj vonalat;

- add meg az ablak méretét stb.

Pl:

- ablak jellemzõi.

(Nem minden request kér válszat!)

Xlib (WM|appl.) -> Xlib (appl.|WM)

Pl:

- keypress, expose, hints stb.

A sebesség növeléséhez technikák:

10.5. Grafikus objektumok manipulálásán alapuló X-es kapcsolattartás

Emlékezzünk az eddig tanult kapcsolattartók

Céljuk: kapcsolat az OS-sel, programindítások, eszköz és fájlkezelés, informálódás, beállítások stb.

Igény merült fel - és a Window-zos rendszerek , köztük az X11 - lehetõvé tették a GUI-t (Graphical User Interface).

Mi kellett a parancsnyelvi kapcsolattartáshoz?

A. Egy OS, mely biztosítja az eszköz és fájlrendszert (szimbolikus nevekkel, hierarchikus szerkezettel). Az OS nek élnie kell, szolgáltató daemon-jainak futnia kell.

B. Kellet egy alfanumerikus terminál (pl VT100), vagy egy ezt emuláló processz, amibõl kapcsolatot kezdeményezhetünk, ülést létesíthetünk.

C. Kellett az init/gtty/login processz. Ez segíti a login/logout-unkat: figyeli a terminál vonalát, kiadja a login promptot, ellenõrzi az uid/passwd párt, végül indít egy shellt.

D. Kell a shell, parancsértelmezõ: a valódi vagy az emulált terminálról jövõ parancsokat értelmezi, paramétereket átvesz, indít processzeket stb.

Mi kell GUI esetén, ha az X-es?

A. Kell az OS, ugyanúgy, mint fent. Az alakalmazások alatta futhatnak majd.

B. Kell egy display (X-es munkahely), ezen kell fusson az X szerver.

Ez lehet X terminál (ennek "beégetett" az X szerver programja).

Lehet egy munkaállomás: azon fusson az X szerver a WS OS-e alatt.

Lehet egy PC is, fusson rajta X szerver.

C1. Az init mellett kell egy X Display Manager (xdm), ami jó, ha a display-en fut. Ez indítja az X szervert, gondozza a "vonalat", login emulációt biztosít (promptot ad, ellenõrzi az uid/passwd párt, ülést biztosít).

Az SGI-ken ez a /usr/bin/X11/xdm, itt az init processz ezt indítja!

VAXstationokon ez a Session Manager.

X terminálokon: sokszor van beégetett xdm, de lehet más gépeken futó xdm is!

PC esetén biztos, hogy más gépen fut az xdm.

AIX alatt: /usr/bin/X11/xdm.

Az X Display Manager az XDMCP protokollt használva menedzseli az X terminálokat, PC-s X szervereket.

C2. Kellhet egy Window Manager is, bár ez nem feltétlenül van! Futhat a display-en, de futhat máshol is.

SGI: 4Dwm (minden WS-en fut).

AIX: mwm (Motif stílusú. A gold-on fut).

Kérdés: Tegyük fel, túl vagyunk a bejelentkezésen, az SGI az X szerver (a display), itt fut a 4Dwm is, és a gold-on fut az alaklamazásunk. Melyik WM - a gold-é vagy az SGI-é - segíti a megjelenítést?

C3. Úgy is bejelentkezhetünk egy host-ra, hogy a display (X szerver) munkahelyen xterm terminálemulációt indítunk, ebbõl az ismert telnet-tel átkapcsolunk egy másik hostra, annak init login/logout-jával sessiont indítunk. Ekkor persze ezen a hoston csak parancsnyelvi kapcsolattartásunk van, igaz indíthatunk majd X-es applikációkat is.

D. Kell végül egy GUI, ami az ablakrendszeren keresztül tartja a kapcsolatot.

azon irattartók,

az irattartókban iratok, további irattartók,

néhány fontos szolgáltatás ikon (pl: levelesláda),

ezek ikonjai stb.

Ismerõs, úgye?

Az SGI-ken ez: Desktop és ...

AIX-on: xdt3 (AIX Desktop)

Legújabban; CDE (Common Desktop Environment)

Figyelem: a GUI programjai: kliensek!

A kliens akárhol futhat! Amelyik hoston fut, azt vezérli!

Így egy jobb fogalmazás: ha valamely hostot vezérelni, kezelni akarom, azon indítsunk GUI klienseket! Ugyanekkor a display (X szerver) lehet más gépen is.

Fontos!

Valamely X szerver (display=munkahely) ellenõrizheti, mely hostok alkalmazásai használhatják õt megjelenítésre. Ezt az engedélyezést alapértelmezésként beállíthatja a superuser:

minden hostról jöhet igény,

csak a display-rõl jöhet igény.

Ezt az engedélyezést állíthatja a munkahely használója is, az xhost paranccsal. (lásd man xhost!)

% xhost # visszadja, mely hostok jeleníthetnek meg itt
% xhost + host@domain...	# engedélyezi a hostot
% xhost - host@domain...	# letiltja a hostot

Továbbá ez is fontos!

Valamely hoston futó alkalmazás honnan tudja, melyik display-t kell használnia a megjelenítéshez?

Az alkalmazásokba "bedrótozhatják", mely display-t használja, de ez nem jó programozási stílus, nem is alkalmazzák.

Szokásos megoldás: az alkalmazás environmentjében a DISPLAY shell változó legyen beállítva a display Internet nevére plussz a képernyõ azonosítására: Így:

DISPLAY=node@domain.domain:n

ahol a node: az a munkahely, ahol az X szerver fut, n: a display-en a képernyõ száma, a mi körülményeink között ez 0 szokott lenni, mert csak egy képernyõsek a munkaállomásaink.

Ezek után feladatok:

1. feladat: Ülök az ind01 elõtt. Szeretném kezelni Toolchest-tel az ind12-t. Mit tegyek?

Az ind01 a display. Ezen fut az X szerver és a 4Dwm. Elõször engedélyeztetnem kell, hogy az ind12 ide dolgozhasson X-esen. Egy ind01 terminálablakban ki kell adni:

ind01% xhost + ind12

Mozdítsuk el a Toolchets ablakot a bal felsó sarokból. Utána egy ablakból telnet-tel jentkezzünk át az ind12-re, jelentkezzünk ott be. Ott egy tc-shell-ünk fog futni. Ellenõrizzük a DISPLAY változót, létezik-e, és az ind01-re mutat-e?

ind12% echo $DISPLAY
Ha ez nem jó setenv paranccsal állítsuk be!

Ha már jó, a toolchest paranccsal indíthatjuk ind12-õn a toolchest-et, az az ind01-re fog dolgozni!

2. feladat: ind01-rõl indítsuk el a gold xclock-ját!

Lépések:

1. ind01-en engedélyezd, hogy gold ide X-esen dolgozzon (xhost + gold).

2. telnet-tel kapcsolatot, majd bejelentkezést a goldra.

3. A goldon ellenõrizd, ha kell állítsd a DISPLAY shell változót. Vigyázz, itt szokásosan a Korn shell indul, annak szintaktikáját használd!

4. Keresd meg a goldon az xclock futtatható programot és indítsd el!

Az erdmény: megjelnik az óra ablaka, az ind01 WM-je segítségével elhelyezheted, mozgathatod, ikonizálhatod, lelõheted. Lelõheted a a gold oldalon is, pl kill paranccsal!

3. feladat: ind01-rõl indítsd a gold óráját, de az az ind02-n jelenjen meg. Megteheted?

4. feladat: valamelyik SGI-rõl indítsuk a gold xdt3-át! Mit kell tenni?

5. feladat: SGI-rõl indítsd a gold info nevû programját. Ez egy hypertext információs anyag az AIX-ról. Érdemes tanulmányozni!

6. feladat: SGI Xsession létesítés.

Az SGI munkaállomások X-es processzei. Az SGI Xsession

Rendszer startup során az init indítja az xdm-et. Az xdm processz indítja az Xsgi-t, ez az X-szerver processz. A futó xdm hasonló szolgáltatásokat biztosít, minta az init/getty/login a karakterorientált terminálon: ülés létesítést segíti, az ülést gondozza. Az xdm szempontjából az ülés (session) egy tetszõleges ülés-menedzser futtatása, ez akár lehet maga az xdm is.

Ezért normális esetben elindítja önmagát, ez az xdm (setup fázis, az Xsetup szerint) ezután bejelentkezési ablakot ad és intézi a login (bejelentkeztetési) eljárást. Ennek eredménye egy sikeres, vagy sikertelen Xsession létesítés. (Van lehetõség más session manager indításra is, ekkor az kezeli az ülést. Végsõ esetben akár alfanumerikus session is létesíthetõ). Mindez a startup fázishoz tartozik, az Xstartup szerint.

Szokásosan a /usr/lib/X11/Xsession.dt fájl szerint indul a session-unk (ezt letilthatjuk, pl. ha van $HOME/.desktop.<hostname>/nodesktop üres fájlunk, vagy ha a rendszermenedzser eleve letiltja az Xsession létesítés lehetõséget stb.)

Ha van $HOME/.xsession shell program fájlunk, akkor ez elindul, bár elsõ esetben figyelmeztetést kapunk, hogy saját stílusú a session létesítõnk.

Ha van $HOME/.chestrc fájlunk, szintén kapunk figyelmeztetést és nem is hajtódik végre a fájl: ez régi stílus, az uj Irix-ben nem használatos.

Most indul el (launched) a 4Dwm ablakmenedzser, de ennek szülõ processze az init lesz.

Ezután indul a toolchest, a szerszámosláda, tartalmát a felhasználó is befolyásolhatja (lásd késõbb).

Ezután idul az fm (Indigo Magic Desktop File Manager) program, amit a desktopManager fog körül (ennek szülõje szintén az init.)

Még mindíg nem fejezõdött be a dolog: ha létezik $HOME/.sgisession fájlunk, az is végrehajtódik. Régi stílus ennek a használata is, régebbi Irix-eknél ezzel a fájllal indítottuk a bejelentekezéseknél szokásos processzeket, ez adott hasonló képet a bejelentkezésekhez. A mai desktop környezete lementõdik, a legközelebbi bejelentkezéskor minazok az elemek felkerülnek a desk-re, amik ott voltak a kilépéskor, ezért mar nincs szükség az .sgisession fájlra.

Mielõtt folytatnánk, megjegyezzük, az Xsession megszüntetése során az xdm az Xresest fázisban "rendbeteszi" a dolgokat.

A grafikus feluletünk szokásosan tehát a Desktop. Ablakok és ikonok gyûjteménye jelenik meg sikeres login után, ez a desk, az íróasztal, amin dolgozunk. Az íróasztalunkon van a toolchest (szerszámosláda), jó esetben egy konzol ablak, amiben egy burok (tcsh) fut, amiben rendszer hibaüzenetek is megjelenhetnek (ezért nem ajánlatos megszüntetni), és a desktop.

A toolchest - többnyire a bal felsõ sarokban - egy lista, egy sor rendszerfunkció végrehajtható elemeinek kiválasztásával. Többszintes, egy-egy eleme kiválasztása újabb menüt adhat, végül azonban processzek indulnak a kiválasztott funkció megvalósítísíra. A menü-hierarchiát a /usr/lib/X11/webtools.chestrc szövegfájl adja, érdemes tanulmányozni. Ez a fájl a rendszer-széles (system-wide) beállításokat tartalmazza. Ehhez hozzáadhatunk elemeket, ha készítünk $HOME/.auxchestrc fájlt, amiban a kívánt formában menüket, azok elemeihez almenüket vagy akciókat fogalmazunk meg.

A konfiguráló fájl tartalma az alábbiakhoz hasonló:

Menu ToolChest
{
	"Desktop"	f.menu 	Desktop
	no-label	f.separator
	"Selected"	f.menu 	Selected
	no-label	f.separator
	"Tools"	f.menu 	Tools
	no-label	f.separator
	"Demos"	f.menu 	Demos
	no-label	f.separator
	"Overview"	f.menu 	Overview
}
Ez definiálja a Toolchest ablakot. A baloldalon szereplõ névlista azokat a neveket tartalmazza, melyek a Toolchest ablakon megjelennek. Az idézõjelekbe tett nevek a menüelemek nevei, az f.menu és az f.separator kifejezések "direktívák". Az f.menu direktívák jobb oldalán szintén nevek vannak: azt határozzák meg, mi történjen, ha a jobboldali név-elemet kiválasztjuk. Például, kiválasztva a "Desktop" szerszám-fiókot, a Desktop menu vezérli a továbbiakat. A fájlban késõbb a Desktop menu definiálva van. A no-label f.separator sorok a Toolchest-en elválasztósorokat generáltatnak.

Nézzük most a Menu Desktop definiálását (Figyelem! Ez a szöveg csak részleteket tartalmaz, és nem is biztos, hogy valóban ezek vannak az említett fájlban!):

Menu Desktop
{
	"Desk Overview"	f.checkexec "/usr/sbin/ov"
	no-label	f.separator
	"Home Dir"	f.checkexec "/usr/lib/desktop/startdesk"
	....
	no-label	f.separator
	....
}

Új direktíva az f.checkexec. Argumentumában adott betölthetõ program létét vizsgálja és ha megtalálja, elindítja. Vegyük észre a paraméterezéseket (nem az itteni példában, hanem a rendszer-széles konfiguráló fájlban)!

Vegyük észre azt is, hogy végsõ soron minden menüelem definícióját meg kell adni, a minta-fájlban adott formákhoz hasonlóan.

Tanulmányozva a fájlt, tudunk mi is újabb menüelemeket "betenni" a Toolchest menürendszerbe.

Gyakorló feladatként a "Tools" menübe tegyünk be egy elemet, ami az xwsh terminálemulációt indítja VT100-a s szabványos terminálként! Ehhez készítsünk $HOME/.auxchestrc fájlt!

Menu ToolChest {
no-label	f.separator
"Tools"	f.menu 	Tools
}
Menu Tools
{

	. . .
	"xwsh"	f.checkexec 	"/usr/sbin/xwsh -vt100"
	no-label 	f.separator
	. . .
}

A rendszer-széles konfiguráló fájl végén még néhány sor van, amit érdemes tanulmányoznunk, megértenünk.

#include the system chests and any user's private chests
sinclude /usr/lib/X11/app-chests
sinclude ~/.auxchestrc

Mi ezek szerepe?

Még egy megjegyzést: ha létezik $HOME/.chestrc fájlunk, aminek konfiguráló fájlnak kell lennie, akkor a rendszer-széles konfigurációs fájl helyett ez alapján készül a toolchest, persze, a dinamikus menuk ekkor eltünnek! Akit érdekel, kipróbálhatja.

A konzol ablakrõl már szóltunk.

A desk lehet még érdekes. Az íróasztal lapja a képernyõ háttér, ebben vannak az ablakok, esetleg a HOME jegyzékünk, mint irattartó, a szemetesláda ikon (dumpster), alkalmazás ikonok lehetnek rajta stb. Mutató (mouse) technikákkal dolgozhatunk az íróasztalon:

Alkalmazásokat futtathatunk:

Mindennaapi feladatok:

Stb.

Nemcsak egy íróasztalunk lehet!

Készíthetünk desk-eket, válthatunk köztyük: mindegyikre valamilyen feladatcsoporthoz tartozó ikonokat, ablakokat összegyüjtve. Próbáljuk ki!