Protocolul principal (rădăcină) al sistemului X Window ( ing. Protocolul de bază al sistemului X Window ) este formatul pentru interacțiunea sistemului X Window , un sistem de ferestre de rețea pentru terminale video raster . X Window se bazează pe un model client-server , adică un server gestionează toate I/O, cum ar fi ecran(e), tastatură și mouse, toate aplicațiile funcționează ca clienți, interacționând cu utilizatorul și alți clienți prin intermediul serverului. Această interacțiune este asigurată de protocolul rădăcină. Există și alte protocoale care sunt atât „suplimente” deasupra rădăcinii și complet independente.
Protocolul rădăcină al sistemului X Window prevede doar 4 tipuri de pachete de date trimise asincron prin rețea: solicitări, răspunsuri, evenimente și mesaje de eroare. Solicitările sunt trimise de către client către server pentru a efectua o acțiune (de exemplu, crearea unei ferestre noi) și/sau pentru a spune serverului să trimită înapoi unele date. Răspunsul serverului asigură că aceste date sunt transmise către client. Evenimentele sunt trimise de un server pentru a-și anunța clienții cu privire la activitatea utilizatorului sau la alte activități de pe partea serverului de care este interesat un anumit client. Mesajele de eroare sunt trimise de server către clientul său în cazul unor erori în procesarea cererilor clientului. Solicitările pot genera răspunsuri, evenimente sau mesaje de eroare. Protocolul nu stabilește o secvență obligatorie pentru transmiterea pachetelor prin rețea. Există extensii la protocolul rădăcină cu propriile cereri, răspunsuri, evenimente sau mesaje de eroare.
System X a apărut la MIT în 1984 (versiunea actuală a X11 este în septembrie 1987). Dezvoltatorul său Bob Shifler și Jim Geths au fost ghidați de regula în timpul dezvoltării sale conform căreia protocolul rădăcină ar trebui să stabilească „un mecanism, nu un set de reguli de politică”. Ca urmare, protocolul rădăcină nu specifică interacțiunea dintre clienți și dintre client și utilizator. Acestea sunt supuse unor specificații suplimentare [1] , cum ar fi ICCCM și Freedesktop.org și sunt de obicei efectuate automat folosind un set predefinit de widget -uri .
Comunicarea între server și clienți se realizează prin schimbul de pachete pe un canal. Conexiunea este stabilită de client (modul de pornire al clientului nu este definit în protocol). În plus, clientul trimite un prim pachet care conține endianitatea de utilizat și informații despre versiunea protocolului, precum și tipul de autentificare așteptat de client, pentru utilizare de către server. Serverul răspunde trimițând înapoi un pachet care confirmă sau respinge conexiunea sau solicitând o autentificare suplimentară. Dacă conexiunea este confirmată, atunci este trimis un pachet care conține datele către client pentru a le utiliza în interacțiunea ulterioară cu serverul.
Odată ce o conexiune este stabilită, patru tipuri de pachete sunt folosite pentru a schimba între client și server prin canal:
Solicitările și răspunsurile sunt trimise în pachete de lungimi diferite, în timp ce pachetele de evenimente și de eroare au o lungime fixă de 32 de octeți .
Ceea ce este denumit în mod obișnuit o fereastră în majoritatea interfețelor grafice cu utilizatorul din sistemul X Window se numește o fereastră de nivel superior. Termenul fereastră este, de asemenea, folosit pentru a se referi la ferestrele care se află într-o altă fereastră, adică o sub fereastră dintr-o fereastră părinte. Elementele grafice precum butoanele, meniurile, pictogramele etc. pot fi implementate folosind o sub fereastră.
Clientul poate solicita crearea unei ferestre. Mai exact, poate solicita crearea unei subferestre în cadrul unei ferestre existente. Ca urmare, ferestrele create de clienți sunt aranjate într-un arbore (ierarhie). Rădăcina acestui arbore este fereastra rădăcină, care este o fereastră specială creată automat la pornirea serverului. Toate celelalte ferestre sunt direct sau indirect subferestre ale ferestrei rădăcină. Ferestrele de nivel superior sunt subferestre directe ale ferestrei rădăcină. Evident, fereastra rădăcină are aceeași dimensiune ca și ecranul (deși poate fi mai mare, caz în care utilizatorul poate muta zona vizibilă) și stă la baza tuturor celorlalte ferestre.
Conținutul unei ferestre nu este întotdeauna garantat a fi păstrat în timp. În special, conținutul unei ferestre poate fi distrus atunci când fereastra este mutată, redimensionată, acoperită de alte ferestre și, în general, făcută complet sau parțial invizibilă. În special, conținutul se pierde dacă serverul X nu acceptă stocarea conținutului ferestrei în memoria auxiliară. Clientul poate solicita ca conținutul ferestrei să fie salvat în memoria auxiliară, dar serverul nu este obligat să facă acest lucru. Astfel, clienții nu pot presupune că există suport pentru memorie auxiliară. Dacă partea vizibilă a ferestrei are conținut nedefinit, evenimentul trimite un mesaj clientului că conținutul ferestrei ar trebui să fie desenat din nou.
Fiecare fereastră are asociat un set de atribute, cum ar fi geometria ferestrei (dimensiune și poziție), imagini de fundal, dacă este solicitată să fie salvată în memoria auxiliară etc. Protocolul conține solicitări către client pentru a verifica și modifica atributele ferestrei .
Windows poate fi InputOutput sau InputOnly. Ferestrele de primul fel pot fi afișate pe ecran și utilizate pentru desen. Al doilea tip de ferestre nu sunt afișate pe ecran, sunt folosite doar pentru a primi intrare.
Chenarul decorativ și bara de titlu (eventual inclusiv butoanele) care sunt văzute în mod obișnuit în jurul ferestrelor sunt create de managerul de ferestre , nu de clientul care creează fereastra. Managerul de ferestre gestionează, de asemenea, intrarea asociată acestor elemente, cum ar fi redimensionarea ferestrei atunci când utilizatorul face clic și trage cadrul ferestrei. Clienții lucrează de obicei într-o fereastră, sunt creați fără a ține cont de modificările făcute de managerul de ferestre. Luați în considerare și acei manageri de ferestre care înlocuiesc fereastra părinte rădăcină comună pentru ferestrele de nivel superior. Majoritatea managerilor de ferestre fac asta acum. Din punctul de vedere al protocolului de bază, managerul de ferestre este un client la fel ca alte aplicații.
Informațiile despre fereastră pot fi obținute prin rularea programului xwininfo. Când rulează din linia de comandă cu argumentul --tree, acest program afișează arborele subferestrelor din fereastră, împreună cu identificatorii și datele geometriei acestora.
Imaginea bitmap este stocată în memoria serverului, nu este afișată pe ecran, dar poate fi desenată integral sau parțial în fereastră. Conținutul unei ferestre poate fi salvat ca bitmap. Acest lucru permite o tamponare dublă. Operațiunile grafice aplicabile Windows sunt, de asemenea, aplicabile bitmap-urilor.
Ferestrele și hărțile de biți sunt numite zone de desen. Conținutul zonelor de desen este stocat pe server. Clientul poate trimite o solicitare pentru a transfera conținutul zonei de la server la client sau invers.
Clientul poate solicita mai multe operațiuni grafice, cum ar fi curățarea unei zone, copierea unei zone în alta, desenarea de puncte, linii, dreptunghiuri și text. Pe lângă curățare, toate operațiunile pot fi efectuate pe toate zonele de desen.
Majoritatea cererilor pentru operații grafice includ un context grafic, o structură de date care conține parametri pentru operații grafice. Contextul grafic include culoarea primului plan, culoarea fundalului, fontul textului și alte setări. La solicitarea operațiunilor grafice, clientul include un context grafic. Nu toate setările contextului grafic afectează funcționarea: de exemplu, fontul nu afectează desenul liniei.
Protocolul de bază impune utilizarea fonturilor de pe partea serverului. Aceste fonturi sunt stocate ca fișiere, iar serverul le accesează direct prin sistemul de fișiere local sau prin rețea folosind un alt program numit server de fonturi. Clientul poate solicita o listă de fonturi disponibile pe server, poate solicita încărcarea unui font pe server (dacă un astfel de font nu este deja pe server) sau poate încărca un font (dacă nu este folosit de alți clienți) pe server-ul. Clientul poate solicita informații despre font (de exemplu, ascensiunea fontului) și spațiul ocupat de o anumită linie atunci când este desenată într-un anumit font.
Numele fonturilor la nivelul protocolului principal X Window sunt șiruri arbitrare. Convenția logică a fonturilor pentru X specifică exact cum ar trebui denumite fonturile în funcție de atributele lor. Aceste convenții specifică, de asemenea, valorile proprietăților suplimentare pe care fonturile le pot avea.
Programul xlsfonts afișează o listă de fonturi stocate pe server, afișează simboluri de font și permite utilizatorului să selecteze un nume de font pentru a lipi într-o altă fereastră.
Redarea fonturilor pe partea serverului este acum considerată depreciată și majoritatea clienților (GTK, Qt) fac deja redarea fonturilor. Pentru a reda fonturile, clienții folosesc bibliotecile Xft sau Cairo și extensiile XRender. Specificația protocolului de bază nu descrie redarea fonturilor pe partea clientului.
Toate datele despre ferestre, bitmaps, fonturi și alte obiecte sunt stocate pe server. Clientul stochează identificatorii (numerele unice) ale acestor obiecte și le folosește ca nume atunci când interacționează cu serverul. De exemplu, un client care dorește să creeze o fereastră trimite o cerere către server pentru a crea o fereastră cu ID-ul dat. Identificatorul poate fi folosit ulterior de client, de exemplu, pentru a solicita linii de desenat pe fereastră. Următoarele obiecte sunt stocate pe server și sunt disponibile clientului prin identificatori digitali:
Aceste obiecte se numesc resurse. Când un client solicită crearea uneia dintre aceste resurse, acesta specifică și identificatorul acesteia . De exemplu, pentru a crea o fereastră nouă, clientul specifică atât atributele ferestrei (părinți, lățime, înălțime și așa mai departe), cât și un identificator asociat ferestrei.
Identificatorii sunt numere întregi pe 32 de biți ai căror trei biți cei mai importanți sunt întotdeauna zero. Fiecare client are propriul set de ID-uri care pot fi folosite pentru a crea resurse noi. Acest set este emis de server într-un pachet de confirmare (pachetul trimis către client pentru a indica faptul că conexiunea a fost acceptată) și este reprezentat ca două numere. Clienții selectează identificatori din acest set în așa fel încât diferite obiecte să aibă identificatori diferiți.
Odată ce o resursă a fost creată, ID-ul acesteia poate fi utilizat de către client în cererile către server. Unele operațiuni afectează aceste resurse (de exemplu, o cerere de mutare a unei ferestre), alte solicitări de resurse stocate pe server (de exemplu, solicitări de atribute de fereastră).
Identificatorii sunt unici nu numai pentru client, ci și pentru server. Deci două ferestre nu pot avea același ID, chiar dacă sunt create de doi clienți diferiți. Un client poate accesa orice obiect prin identificatorul său (chiar și obiectul altui client).
Ca rezultat, doi clienți conectați la același server pot folosi același identificator pentru a se referi la aceeași resursă. De exemplu, dacă un client creează o fereastră cu ID 0x1e00021 și transmite acel număr 0x1e00021 unei alte aplicații (prin orice mijloace disponibile, cum ar fi salvarea acelui număr într-un fișier accesibil și altor aplicații), atunci acea altă aplicație poate rula pe aceeași aplicație. fereastra.. Această caracteristică, de exemplu, este utilizată de versiunea X Window a programului Ghostview : acest program creează o fereastră copil, își stochează identificatorul într- o variabilă de mediu și apelează Ghostscript , care desenează conținutul fișierului PostScript și îl afișează în acest fereastra [8].
Resursele sunt de obicei distruse după ce clientul care le-a creat închide conexiunea la server. Cu toate acestea, înainte de a închide conexiunea, clientul poate trimite o cerere către server prin care îi cere să nu le distrugă.
Evenimentele sunt pachete trimise de server către client, cu un mesaj că s-a întâmplat ceea ce se aștepta clientul. De exemplu, un eveniment este trimis atunci când utilizatorul apasă pe o tastă sau pe un buton al mouse-ului. Evenimentele pot fi folosite pentru mai mult decât pentru introducere: de exemplu, evenimentele trimit o indicație pentru a crea noi subferestre într-o fereastră dată.
Fiecare eveniment este asociat cu o fereastră. De exemplu, dacă utilizatorul face clic pe mouse, evenimentul se va referi la fereastra pe care se afla cursorul în momentul clicului. Pachetul de eveniment va conține ID-ul acestei ferestre.
Clientul poate cere serverului să trimită un eveniment către alt client. Acesta este folosit pentru a organiza interacțiunea dintre clienți. Un astfel de eveniment, de exemplu, este generat atunci când un client solicită textul selectat și este trimis de server către clientul care deține fereastra cu textul selectat.
Un eveniment Exposeeste expediat de server dacă imaginea zonei ferestrei clientului a fost ștearsă din memorie și fereastra devine vizibilă. Imaginea ferestrei este ștearsă din memorie dacă fereastra a fost minimizată, acoperită de o altă fereastră și în alte cazuri.
Cele mai multe tipuri de evenimente sunt trimise clientului doar dacă acesta și-a declarat anterior interesul pentru ele. De exemplu, un client ar putea fi interesat de evenimentele de la tastatură, dar nu de evenimentele mouse-ului. În ciuda acestui fapt, unele tipuri de evenimente sunt transmise clienților chiar dacă aceștia nu le-au solicitat în mod expres.
Clientul selectează tipurile de evenimente necesare setând un atribut special de fereastră - masca de eveniment. De exemplu, pentru a începe să deseneze conținutul unei ferestre, clientul trebuie să primească fișierul Expose. Serverul, totuși, va trimite acest eveniment numai dacă clientul a setat bitul corespunzător în masca de eveniment a ferestrei.
Clienți diferiți pot solicita evenimente din aceeași fereastră. Ei pot chiar seta diferite măști de evenimente pe aceeași fereastră. De exemplu, un client poate solicita doar evenimente de la tastatură, în timp ce altul poate solicita doar evenimente de mouse. Cu toate acestea, există mai multe tipuri de evenimente care pot fi livrate doar unui singur client. În special, acestea sunt evenimente de mesaje de clic de mouse și unele modificări legate de gestionarea ferestrelor.
xev- un program care arată evenimente în legătură cu fereastra. În special, comanda xev -id WIDinterogează toate evenimentele posibile privind fereastra cu identificatorul WIDși le imprimă.
Următorul este un exemplu de posibilă interacțiune între un server și un program care creează o fereastră cu o imagine cutie neagră și iese din apăsările de taste. În acest exemplu, serverul nu trimite niciun răspuns deoarece clientul trimite o cerere care nu generează răspunsuri. Aceste interogări pot genera erori.
Dacă o fereastră se suprapune cu o altă fereastră și nu o suprapune din nou, cu condiția ca magazinul de suport să nu fie gestionat, atunci:
La nivel de protocol, o culoare este reprezentată de un număr întreg fără semn pe 32 de biți numit pixelvalue . La reprezentarea culorilor iau parte următoarele elemente:
În cel mai simplu caz, o hartă de culori conține o triadă RGB într-un rând. pixelvalue xeste al x-lea rând din tabel. Dacă clientul poate modifica intrările din harta de culori, atunci vizualizarea este identificată cu clasa vizuală PseudoColor . Clasa vizuală StaticColoreste similară, dar clientul nu poate modifica intrările din tabelul de culori.
Sunt disponibile un total de 6 clase vizuale. Fiecare este definit printr-un mod diferit de a reprezenta o triadă RGB cu o valoare pixel. PseudoColoriar StaticColorprimele două. Următoarele două - GrayScaleși StaticGray, diferă prin faptul că arată doar nuanțe de gri.
Celelalte două clase vizuale diferă de cele de mai sus prin faptul că nu folosesc triada pixelvalue, ci folosesc trei tabele diferite pentru valorile intensității roșu, verde și albastru.
Conform reprezentării culorilor, pixelvalue se convertește în triada RGB în următoarele cazuri:
Acest mecanism necesită ca harta de culori să fie compusă din trei tabele separate, fiecare pentru una dintre culorile primare. Rezultatul transformării sunt alte trei valori de intensitate. Clasele vizuale utilizate de această vizualizare sunt: DirectColorsau TrueColor, diferă prin faptul că clientul poate schimba sau nu harta de culori.
Toate aceste șase mecanisme pentru reprezentarea culorilor cu valoarea pixelilor necesită niște parametri suplimentari pentru a funcționa. Aceste opțiuni sunt colectate într-un tip vizual care conține clasa vizuală și restul opțiunilor de reprezentare a culorilor. Fiecare server are un număr limitat de tipuri vizuale instalate și fiecare tip este asociat cu un identificator numeric. Identificatorii sunt numere întregi nesemnate pe 32 de biți, dar nu sunt neapărat diferiți de identificatorii de resurse sau de atomi.
Când o conexiune este acceptată de la client, pachetul de confirmare trimis către server conține o secvență de blocuri, fiecare conținând informații despre un ecran. Pentru fiecare ecran, blocurile relative conțin o listă de alte blocuri, fiecare bloc relativ definește adâncimea de culoare suportată de ecran. Pentru fiecare adâncime de culoare, această listă conține tipurile vizuale. Ca urmare, fiecare ecran este asociat cu unele posibile valori de adâncime a culorii, iar fiecare adâncime de culoare a fiecărui ecran este asociată cu posibile tipuri vizuale. Aceste tipuri vizuale pot fi utilizate pentru alte ecrane și diferite adâncimi de culoare.
Pentru fiecare tip vizual, pachetul de confirmare conține atât acești identificatori, cât și parametrii actuali de conținut (tip vizual, etc.) Clientul stochează aceste informații, deoarece nu va mai putea solicita aceste informații în viitor. În plus, clienții nu pot schimba sau crea noi tipuri vizuale. Solicitările de creare a unei ferestre noi includ adâncimea culorii și identificatorul de tip vizual pentru afișarea culorilor în fereastra respectivă.
Hărțile de culori sunt utilizate independent de hardware-ul care controlează ecranul (adică, placa video poate folosi sau nu o paletă (tabel de culori). Serverele folosesc hărți de culori chiar dacă hardware-ul nu folosește o paletă. Când hardware-ul utilizează palete, se poate instala un număr limitat de hărți de culori. În special, hărțile de culori sunt setate atunci când hardware-ul arată culori consistente. Clientul poate solicita serverului să instaleze o hartă de culori. Cu toate acestea, aceasta poate necesita eliminarea unei alte hărți de culori: efectul utilizării hărții de culori eliminate va fi o imagine cu culori incorecte, un efect de rafală de culoare dublă sau culori de intensitate ridicată. Această problemă poate fi rezolvată prin utilizarea hărților de culori standard. Acestea sunt hărți de culori cu asocieri predefinite între valorile pixelilor și culori. Datorită acestei calități, hărțile de culori standard pot fi utilizate de diverse aplicații.
Crearea hărților de culoare este guvernată de acordul ICCCM. Hărțile de culori standard sunt definite de ICCCM și specificația Xlib.
O parte a sistemului de culori X este X Color Management System (xcms). Acest sistem a apărut cu X11R6 Release 5 în 1991. Acest sistem este conținut sub forma mai multor caracteristici suplimentare Xlib găsite într-o serie de funcții ale căror nume încep cu Xcms. Sistemul definește scheme de culori independente de dispozitiv care pot fi deja convertite în sisteme RGB dependente de dispozitiv. Sistemul conține funcțiile Xlib Xcms*, precum și Convenția X Device Color Characterization Convention (XDCCC) care descrie modul în care diferite sisteme de culoare independente de dispozitiv sunt convertite în sisteme de culoare RGB dependente de dispozitiv. Acest sistem acceptă sistemele de culoare CIEXYZ, xyY, CIELUV și CIELAB, precum și TekHVC.
| Sistemul X Window | |
|---|---|
| Arhitectură |
|
| Managerii de ferestre | |
| Extensii |
|
| Implementări | |
| Standarde | |
| Aplicații |
|