Az X Window System fő (gyökér) protokollja (az X Window System magprotokollja ) az X Window rendszer interakciójának formátuma , egy hálózati ablakrendszer a raszteres videoterminálokhoz . Az X Window kliens-szerver modellen alapul, azaz egy szerver kezeli az összes I/O-t, mint például a képernyő(ke)t, a billentyűzetet és az egeret, minden alkalmazás kliensként működik, a szerveren keresztül kommunikálva a felhasználóval és más kliensekkel. Ezt az interakciót a root protokoll biztosítja. Vannak más protokollok is, amelyek „kiegészítők” a gyökér tetején, és teljesen függetlenek.
Az X Window System gyökér protokollja mindössze 4 típusú adatcsomagot biztosít aszinkron módon a hálózaton keresztül: kéréseket, válaszokat, eseményeket és hibaüzeneteket. A kliens kéréseket küld a szervernek, hogy hajtson végre valamilyen műveletet (például hozzon létre egy új ablakot) és/vagy utasítsa a szervert, hogy küldjön vissza bizonyos adatokat. A szerver válasza biztosítja, hogy ezeket az adatokat továbbítsák a kliensnek. Az eseményeket a szerver küldi el, hogy értesítse ügyfeleit azokról a felhasználói tevékenységekről vagy más szerveroldali tevékenységekről, amelyek iránt egy adott ügyfél érdeklődik. A szerver hibaüzeneteket küld a kliensének, ha az ügyfélkérések feldolgozása során hiba lép fel. A kérések válaszokat, eseményeket vagy hibaüzeneteket generálhatnak. A protokoll nem határoz meg kötelező sorrendet a csomagok hálózaton keresztüli továbbítására. A gyökérprotokollnak vannak kiterjesztései saját kérésekkel, válaszokkal, eseményekkel vagy hibaüzenetekkel.
A System X 1984-ben jelent meg az MIT -n (az X11 jelenlegi verziója 1987 szeptemberében jelent meg). Fejlesztőjét, Bob Shiflert és Jim Gethst az a szabály vezérelte a fejlesztés során, hogy a gyökér protokollnak "egy mechanizmust kell létrehoznia, nem pedig szabályrendszert". Ennek eredményeként a root protokoll nem határozza meg az ügyfelek közötti, illetve az ügyfél és a felhasználó közötti interakciót. Ezekre további specifikációk vonatkoznak [1] , mint például az ICCCM és a Freedesktop.org , és általában automatikusan, előre meghatározott widgetkészlettel hajtják végre őket .
A szerver és az ügyfelek közötti kommunikáció egy csatornán keresztüli csomagcserével történik. A kapcsolatot a kliens hozza létre (a kliens indításának módja nincs meghatározva a protokollban). Ezen túlmenően a kliens elküld egy első csomagot, amely tartalmazza a használandó végpontot és információkat a protokoll verziójáról, valamint a kliens által elvárt hitelesítés típusáról a szerver számára. A szerver válaszként visszaküld egy csomagot, amely megerősíti vagy megtagadja a kapcsolatot, vagy további hitelesítést kér. Ha a kapcsolat megerősítést nyer, akkor az adatokat tartalmazó csomagot küld a kliensnek a szerverrel való későbbi interakcióhoz.
Miután létrejött a kapcsolat, négyféle csomagot használnak a kliens és a szerver közötti csatornán keresztüli cserére:
A kérések és válaszok változó hosszúságú csomagokban kerülnek elküldésre, míg az esemény- és hibacsomagok rögzített hossza 32 bájt .
Amit az X Window System legtöbb grafikus felhasználói felületén ablaknak neveznek, legfelső szintű ablaknak nevezik. Az ablak kifejezést olyan ablakokra is használják, amelyek egy másik ablakon belül vannak, vagyis egy szülőablak egy alablakát. Grafikus elemek, például gombok, menük, ikonok stb., egy alablak segítségével valósíthatók meg.
Az ügyfél kérheti egy ablak létrehozását. Pontosabban kérheti egy meglévő ablakon belüli alablak létrehozását. Ennek eredményeként az ügyfelek által létrehozott ablakok egy fába (hierarchiába) kerülnek. Ennek a fának a gyökere a gyökérablak, amely egy speciális ablak, amely a szerver indításakor automatikusan létrejön. Az összes többi ablak közvetlenül vagy közvetve a gyökérablak alablakja. A legfelső szintű ablakok a gyökérablak közvetlen alablakai. Nyilvánvaló, hogy a gyökérablak akkora, mint a képernyő (bár lehet, hogy nagyobb is, ebben az esetben a felhasználó mozgathatja a látható területet), és az összes többi ablak alatt van.
Az ablak tartalmának megőrzése nem mindig garantált. Az ablak tartalma különösen akkor sérülhet meg, amikor az ablakot elmozdítják, átméretezik, más ablakok takarják, és általában teljesen vagy részben láthatatlanná teszik. A tartalom különösen akkor vész el, ha az X szerver nem támogatja az ablak tartalmának a kiegészítő memóriában való tárolását. A kliens kérheti, hogy az ablak tartalmát a segédmemóriába mentse, de a szervernek erre nincs szüksége. Így az ügyfelek nem feltételezhetik, hogy létezik kiegészítő memória támogatás. Ha az ablak látható része definiálatlan tartalommal rendelkezik, az esemény üzenetet küld a kliensnek, hogy az ablak tartalmát újra meg kell rajzolni.
Minden ablakhoz tartozik egy attribútumkészlet, mint például az ablak geometriája (mérete és pozíciója), háttérképek, kérik-e a mentést a kiegészítő memóriába stb. A protokoll kéréseket tartalmaz a klienshez, hogy ellenőrizze és módosítsa az ablak attribútumait .
A Windows lehet InputOutput vagy InputOnly. Az első típusú ablakok megjeleníthetők a képernyőn, és rajzolásra használhatók. A második típusú ablakok nem jelennek meg a képernyőn, csak bemenet fogadására szolgálnak.
Az ablakok körül gyakran látható dekoratív szegélyt és címsort (esetleg gombokat is beleértve) az ablakkezelő hozza létre, nem pedig az ablakot létrehozó ügyfél. Az ablakkezelő kezeli az ezekhez az elemekhez társított bevitelt is, például az ablak átméretezését, amikor a felhasználó rákattint és elhúzza az ablakkeretet. A kliensek általában ablakban dolgoznak, az ablakkezelő által végrehajtott változtatások figyelembevétele nélkül jönnek létre. Vegye figyelembe azokat az ablakkezelőket is, amelyek a legfelső szintű ablakok közös gyökér szülőablakát helyettesítik. A legtöbb ablakkezelő most ezt teszi. A mögöttes protokoll szempontjából az ablakkezelő a többi alkalmazáshoz hasonlóan kliens.
Az ablakkal kapcsolatos információk az xwininfo program futtatásával szerezhetők be. Ha a parancssorból futtatja a --tree argumentummal, akkor ez a program megjeleníti az ablakból az alablakok fáját, azok azonosítóival és geometriai adataival együtt.
A bitmap kép a szerver memóriájában tárolódik, nem jelenik meg a képernyőn, hanem részben vagy egészben berajzolható az ablakba. Egy ablak tartalma bittérképként menthető. Ez lehetővé teszi a dupla pufferelést. A Windowsra vonatkozó grafikai műveletek a bittérképekre is alkalmazhatók.
Az ablakokat és a bitképeket rajzterületeknek nevezzük. A rajzterületek tartalma a szerveren tárolódik. A kliens kérést küldhet a terület tartalmának átvitelére a szerverről a kliensre, vagy fordítva.
A kliens többféle grafikus műveletet is kérhet, mint például egy terület törlése, terület másolása másikra, pontok, vonalak, téglalapok és szöveg rajzolása. A törlés mellett minden művelet elvégezhető az összes rajzterületen.
A legtöbb grafikus műveletre vonatkozó kérés tartalmaz egy grafikus környezetet, egy adatstruktúrát, amely a grafikus műveletek paramétereit tartalmazza. A grafikai környezet magában foglalja az előtér színét, a háttér színét, a szöveg betűtípusát és egyéb beállításokat. Grafikus műveletek kérésekor az ügyfél grafikus kontextust tartalmaz. Nem minden grafikus környezetbeállítás befolyásolja a műveletet: például a betűtípus nincs hatással a vonal rajzolására.
Az alapprotokoll kiszolgálóoldali betűtípusok használatát írja elő. Ezek a betűkészletek fájlként vannak tárolva, és a szerver közvetlenül a helyi fájlrendszeren keresztül vagy a hálózaton keresztül éri el őket egy másik, fontszervernek nevezett program segítségével. A kliens kérheti a szerveren elérhető betűtípusok listáját, kérhet valamilyen betűtípus feltöltését a szerverre (ha ilyen betűtípus még nincs a szerveren), vagy feltölthet egy betűtípust (ha más kliensek nem használják) a szerver. Az ügyfél információkat kérhet a betűtípusról (például a betűtípus emelkedéséről) és az adott vonal által elfoglalt területről, ha egy adott betűtípussal rajzolják.
A fő X Window protokoll szintjén lévő betűtípusnevek tetszőleges karakterláncok. Az X logikai betűtípus-konvenciója pontosan meghatározza, hogyan kell a betűtípusokat attribútumuk szerint elnevezni. Ezek a konvenciók meghatározzák a betűtípusok további tulajdonságainak értékeit is.
Az xlsfonts program megjeleníti a kiszolgálón tárolt betűtípusok listáját, megjeleníti a betűtípus szimbólumokat, és lehetővé teszi a felhasználó számára, hogy válasszon egy betűtípusnevet, amelyet egy másik ablakba szeretne beilleszteni.
A kiszolgálóoldali betűkészlet-megjelenítés már elavultnak számít, és a legtöbb kliens (GTK, Qt) már végez betűkészlet-megjelenítést. A betűtípusok megjelenítéséhez az ügyfelek az Xft vagy a cairo könyvtárakat és az XRender kiterjesztéseket használják. Az alapprotokoll-specifikáció nem írja le az ügyféloldali betűkészlet-megjelenítést.
Az ablakokkal, bitképekkel, betűtípusokkal és egyéb objektumokkal kapcsolatos összes adat a szerveren tárolódik. A kliens tárolja ezen objektumok azonosítóit (egyedi számait), és névként használja a szerverrel való interakció során. Például egy ablakot létrehozni kívánó kliens kérést küld a szervernek, hogy hozzon létre egy ablakot a megadott azonosítóval. Az azonosítót a kliens később felhasználhatja például arra, hogy vonalakat kérjen az ablakra. A következő objektumok a szerveren vannak tárolva, és digitális azonosítókon keresztül elérhetők a kliens számára:
Ezeket az objektumokat erőforrásoknak nevezzük. Amikor egy ügyfél az egyik ilyen erőforrás létrehozását kéri, megadja annak azonosítóját is . Például egy új ablak létrehozásához az ügyfél megadja az ablak attribútumait (szülők, szélesség, magasság stb.) és az ablakhoz társított azonosítót.
Az azonosítók 32 bites egész számok , amelyek három legjelentősebb bitje mindig nulla. Minden ügyfélnek saját azonosítókészlete van, amelyek segítségével új erőforrásokat hozhat létre. Ezt a készletet a szerver egy nyugtázási csomagban adja ki (az ügyfélnek küldött csomag, amely jelzi, hogy a kapcsolat elfogadásra került), és két számként jelenik meg. Az ügyfelek ebből a készletből választanak ki azonosítókat úgy, hogy a különböző objektumok eltérő azonosítóval rendelkezzenek.
Az erőforrás létrehozása után az azonosítóját a kliens felhasználhatja a kiszolgálóhoz intézett kérésekben. Egyes műveletek hatással vannak ezekre az erőforrásokra (például egy ablak áthelyezésére vonatkozó kérés), más, a kiszolgálón tárolt erőforrásokra vonatkozó kérések (például ablakattribútumokra vonatkozó kérések).
Az azonosítók nem csak a kliens, hanem a szerver számára is egyediek. Tehát két ablaknak nem lehet ugyanaz az azonosítója, még akkor sem, ha két különböző kliens hozta létre. A kliens bármely objektumhoz hozzáférhet az azonosítója alapján (akár egy másik kliens objektumához is).
Ennek eredményeként két, ugyanahhoz a kiszolgálóhoz kapcsolódó kliens ugyanazt az azonosítót használhatja ugyanarra az erőforrásra való hivatkozáshoz. Például, ha egy kliens létrehoz egy ablakot 0x1e00021 azonosítóval, és átadja a 0x1e00021 számot egy másik alkalmazásnak (bármilyen elérhető módon, például elmenti a számot egy fájlba, amely más alkalmazások számára is elérhető), akkor az a másik alkalmazás futhat ugyanazon ablak.. Ezt a szolgáltatást például a Ghostview program X Window verziója használja : ez a program létrehoz egy gyermekablakot, eltárolja az azonosítóját egy környezeti változóban , és meghívja a Ghostscriptet , amely kirajzolja a PostScript fájl tartalmát, és megjeleníti azt ebben. ablak [8].
Az erőforrások általában megsemmisülnek, miután az őket létrehozó ügyfél lezárja a kapcsolatot a kiszolgálóval. A kapcsolat lezárása előtt azonban a kliens kérést küldhet a szervernek, hogy ne semmisítse meg őket.
Az események olyan csomagok, amelyeket a szerver küld a kliensnek, üzenettel, hogy az történt, amit a kliens várt. Például egy esemény akkor kerül elküldésre, amikor a felhasználó megnyom egy billentyűt vagy megnyom egy egérgombot. Az események nem csak bevitelre használhatók: például az események jelzést küldenek új alablakok létrehozására egy adott ablakban.
Minden eseményhez egy ablak tartozik. Például, ha a felhasználó rákattint az egérrel, az esemény arra az ablakra hivatkozik, amelyen a kurzor a kattintás időpontjában állt. Az eseménycsomag ennek az ablaknak az azonosítóját fogja tartalmazni.
Az ügyfél kérheti a szervert, hogy küldjön eseményt egy másik kliensnek. Ez az ügyfelek közötti interakció megszervezésére szolgál. Ilyen esemény például akkor jön létre, amikor egy kliens kiválasztott szöveget kér, és a szerver elküldi a kiválasztott szöveggel rendelkező ablakot birtokló ügyfélnek.
A szerver akkor küld eseményt Expose, ha a kliens ablakterületének képét törölték a memóriából, és az ablak láthatóvá válik. Az ablak képe törlődik a memóriából, ha az ablakot kicsinyítették, egy másik ablak takarta el, és más esetekben.
A legtöbb eseménytípust csak akkor küldjük el az ügyfélnek, ha korábban jelezte érdeklődését iránta. Előfordulhat például, hogy egy kliens a billentyűzet-események iránt érdeklődik, az egéresemények azonban nem. Ennek ellenére bizonyos típusú eseményeket akkor is átadnak az ügyfeleknek, ha nem kifejezetten kérték.
A kliens egy speciális ablakattribútum - az eseménymaszk - beállításával választja ki a kívánt eseménytípusokat. Például egy ablak tartalmának rajzolásához az ügyfélnek meg kell kapnia a Expose. A szerver azonban csak akkor küldi el ezt az eseményt, ha a kliens beállította a megfelelő bitet az ablak eseménymaszkjában.
Különböző kliensek kérhetnek eseményeket ugyanabból az ablakból. Még különböző eseménymaszkokat is beállíthatnak ugyanabban az ablakban. Például az egyik kliens csak billentyűzet-eseményeket kérhet, míg egy másik csak egéreseményeket. Vannak azonban olyan események, amelyeket csak egy ügyfélnek lehet kézbesíteni. Ezek különösen az egérkattintásos üzenetesemények és néhány ablakkezeléssel kapcsolatos változás.
xev- az eseményeket az ablakhoz viszonyítva megjelenítő program. A parancs különösen xev -id WIDaz azonosítóval rendelkező ablakkal kapcsolatos összes lehetséges eseményt lekérdezi WIDés kinyomtatja.
Az alábbi példa egy lehetséges interakciót mutat be egy szerver és egy olyan program között, amely egy ablakot hoz létre egy fekete doboz képével, és kilép a billentyűleütésekből. Ebben a példában a szerver nem küld választ, mert az ügyfél olyan kérést küld, amely nem generál választ. Ezek a lekérdezések hibákat generálhatnak.
Ha egy ablak átfed egy másik ablakot, és nem fedi át újra, feltéve, hogy a háttértár nincs kezelve, akkor:
A protokoll szintjén egy színt egy 32 bites előjel nélküli egész szám képvisel, amelyet pixelvalue -nak neveznek . A következő elemek vesznek részt a színábrázolásban:
A legegyszerűbb esetben a színtérkép egy RGB hármast tartalmaz egy karakterláncban. pixelvalue xa táblázat x. sora. Ha a kliens módosíthatja a színtérkép bejegyzéseit, akkor a nézet a vizuális osztállyal PseudoColor lesz azonosítva . A vizuális osztály StaticColorhasonló, de az ügyfél nem tudja megváltoztatni a színtáblázat bejegyzéseit.
Összesen 6 vizuális osztály áll rendelkezésre. Mindegyiket egy pixelértékkel rendelkező RGB-triád más-más megjelenítési módja határozza meg. PseudoColorés StaticColoraz első kettő. A következő két - GrayScaleés StaticGray, abban különbözik, hogy csak a szürke árnyalatait mutatják.
A fennmaradó két vizuális osztály abban különbözik a fentiektől, hogy nem a pixelvalue triádot használják, hanem három különböző táblázatot használnak a vörös, zöld és kék intenzitásértékekhez.
A színek megjelenítésének megfelelően a pixelvalue a következő esetekben konvertálódik RGB hármassá:
Ez a mechanizmus megköveteli, hogy a színtérkép három különálló táblázatból álljon, mindegyik az egyik elsődleges színhez. A transzformáció eredménye további három intenzitásérték. Az ebben a nézetben használt vizuális osztályok a következők: DirectColorvagy TrueColor, abban különböznek, hogy az ügyfél módosíthatja a színtérképet vagy sem.
A színek pixelértékkel történő megjelenítésére szolgáló hat mechanizmus mindegyike további paramétereket igényel. Ezeket a beállításokat olyan vizuális típusban gyűjtöttük össze, amely tartalmazza a vizuális osztályt és a színek megjelenítésének többi beállítását. Minden kiszolgálóhoz korlátozott számú telepített vizuális típus tartozik, és mindegyik típushoz numerikus azonosító tartozik. Az azonosítók 32 bites előjel nélküli egész számok, de nem feltétlenül különböznek az erőforrás- vagy atomazonosítóktól.
Amikor a kapcsolat elfogadásra kerül az ügyféltől, a kiszolgálónak küldött nyugtázási csomag blokkok sorozatát tartalmazza, amelyek mindegyike egy képernyőről tartalmaz információt. Minden képernyőhöz a relatív blokkok tartalmazzák a többi blokk listáját, minden relatív blokk határozza meg a képernyő által támogatott színmélységet. Ez a lista minden színmélységhez tartalmazza a vizuális típusokat. Ennek eredményeként az egyes képernyők néhány lehetséges színmélység értékkel, az egyes képernyők színmélysége pedig lehetséges vizuális típusokkal van társítva. Ezek a vizuális típusok más képernyőkhöz és különböző színmélységekhez is használhatók.
A nyugtázási csomag minden egyes vizuális típusnál tartalmazza ezeket az azonosítókat és a tényleges tartalmi paramétereket (vizuális típus, stb.) A kliens tárolja ezeket az információkat, mivel a jövőben nem tudja újra kérni. Ezenkívül az ügyfelek nem módosíthatnak vagy nem hozhatnak létre új vizuális típusokat. Az új ablak létrehozására vonatkozó kérések magukban foglalják a színmélységet és a vizuális típusazonosítót az ablakban lévő színek megjelenítéséhez.
A színtérképek a képernyőt vezérlő hardvertől függetlenül használatosak (azaz a videokártya használhat palettát (színtáblázat) vagy nem). A szerverek akkor is használnak színtérképet, ha a hardver nem használ palettát. Ha a hardver palettákat használ, korlátozott számú színtérkép telepíthető. A színtérképek különösen akkor vannak beállítva, ha a hardver konzisztens színeket mutat. A kliens kérheti a szervertől egy színtérkép telepítését. Ehhez azonban szükség lehet egy másik színtérkép eltávolítására: az eltávolított színtérkép használatának hatása hibás színekkel, kettős színsorozat-effektussal vagy nagy intenzitású színekkel jár. Ezt a problémát szabványos színtérképek használatával lehet megoldani. Ezek színtérképek előre meghatározott asszociációkkal a pixelértékek és a színek között. Ennek a minőségnek köszönhetően a szabványos színtérképek különféle alkalmazásokban használhatók.
A színes térképek létrehozását az ICCCM megállapodás szabályozza. A szabványos színtérképeket az ICCCM és az Xlib specifikáció határozza meg.
Az X színrendszer része az X Color Management System (xcms). Ez a rendszer az X11R6 Release 5-tel jelent meg 1991-ben. Ez a rendszer számos további Xlib-funkció formájában található meg, amelyek egy sor függvényben találhatók, amelyek neve Xcms-szel kezdődik. A rendszer eszközfüggetlen színsémákat határoz meg, amelyek már átalakíthatók eszközfüggő RGB-rendszerekké. A rendszer tartalmazza az Xlib Xcms* funkciókat, valamint az X Device Color Characterization Convention (XDCCC) szabványt, amely leírja, hogy a különböző eszközfüggetlen színrendszerek hogyan konvertálhatók eszközfüggő RGB színrendszerekké. Ez a rendszer támogatja a CIEXYZ, xyY, CIELUV és CIELAB színrendszereket, valamint a TekHVC-t.
| X Window System | |
|---|---|
| Építészet |
|
| Ablakkezelők |
|
| Kiterjesztések |
|
| Megvalósítások | |
| Szabványok | |
| Alkalmazások |
|