Hovedprotokollen (rod) for X Window System ( eng. X Window System core protocol ) er formatet for interaktionen af X Window-systemet , et netværksvinduesystem til rastervideoterminaler . X-vinduet er baseret på en klient-server- model, dvs. én server administrerer alle I/O såsom skærm(e), tastatur og mus, alle applikationer fungerer som klienter og interagerer med brugeren og andre klienter gennem serveren. Denne interaktion leveres af rodprotokollen. Der er også andre protokoller, der både er "add-ons" oven på roden, og helt uafhængige.
Rodprotokollen for X Window System giver kun 4 typer datapakker sendt asynkront over netværket: anmodninger, svar, hændelser og fejlmeddelelser. Anmodninger sendes af klienten til serveren om at udføre en handling (for eksempel oprette et nyt vindue) og/eller bede serveren om at sende nogle data tilbage. Serversvaret sikrer, at disse data videresendes til klienten. Hændelser sendes af en server for at underrette sine klienter om brugeraktivitet eller anden aktivitet på serversiden, som en bestemt klient er interesseret i. Fejlmeddelelser sendes af serveren til sin klient i tilfælde af fejl i behandlingen af klientanmodninger. Anmodninger kan generere svar, hændelser eller fejlmeddelelser. Protokollen etablerer ikke en obligatorisk sekvens for transmission af pakker over netværket. Der er udvidelser til rodprotokollen med deres egne anmodninger, svar, hændelser eller fejlmeddelelser.
System X dukkede op på MIT i 1984 (den nuværende version af X11 er i september 1987). Dens udvikler Bob Shifler og Jim Geths blev styret af reglen under dens udvikling, at rodprotokollen skulle etablere "en mekanisme, ikke et sæt af politiske regler." Som et resultat specificerer rodprotokollen ikke interaktionen mellem klienter og mellem klient og bruger. De er underlagt yderligere specifikationer [1] såsom ICCCM og Freedesktop.org og udføres normalt automatisk ved hjælp af et foruddefineret sæt widgets .
Kommunikation mellem serveren og klienterne udføres ved at udveksle pakker over en kanal. Forbindelsen etableres af klienten (hvordan klienten starter er ikke defineret i protokollen). Derudover sender klienten en første pakke indeholdende endianness, der skal bruges, og information om protokolversionen, samt typen af autentificering, der forventes af klienten, til brug for serveren. Serveren svarer ved at sende en pakke tilbage, der bekræfter eller afviser forbindelsen, eller anmoder om yderligere godkendelse. Hvis forbindelsen bekræftes, sendes en pakke indeholdende dataene til klienten til brug i efterfølgende interaktion med serveren.
Når en forbindelse er etableret, bruges fire typer pakker til at udveksle mellem klienten og serveren over kanalen:
Forespørgsler og svar sendes i pakker af varierende længde, mens hændelses- og fejlpakker har en fast længde på 32 bytes .
Det, der almindeligvis omtales som et vindue i de fleste grafiske brugergrænseflader i X Window System, kaldes et vindue på øverste niveau. Udtrykket vindue bruges også til at henvise til vinduer, der ligger inden for et andet vindue, det vil sige et undervindue fra et overordnet vindue. Grafiske elementer såsom knapper, menuer, ikoner osv. kan implementeres ved hjælp af et undervindue.
Klienten kan anmode om oprettelse af et vindue. Mere præcist kan den anmode om oprettelse af et undervindue i et eksisterende vindue. Som et resultat er vinduer, der er oprettet af klienter, arrangeret i et træ (hierarki). Roden af dette træ er rodvinduet, som er et specielt vindue, der oprettes automatisk, når serveren starter. Alle andre vinduer er direkte eller indirekte undervinduer til rodvinduet. Vinduer på øverste niveau er direkte undervinduer til rodvinduet. Det er klart, at rodvinduet har samme størrelse som skærmen (selvom det kan være større, i hvilket tilfælde brugeren kan flytte det synlige område) og ligger under alle andre vinduer.
Indholdet af et vindue er ikke altid garanteret at blive bevaret over tid. Især kan indholdet af et vindue blive ødelagt, når vinduet flyttes, ændres størrelse, dækkes af andre vinduer og generelt gøres helt eller delvist usynligt. Især går indholdet tabt, hvis X-serveren ikke understøtter lagring af vinduets indhold i hjælpehukommelsen. Klienten kan anmode om, at indholdet af vinduet gemmes i hjælpehukommelsen, men serveren er ikke forpligtet til at gøre det. Klienter kan således ikke antage, at der findes understøttelse af ekstra hukommelse. Hvis den synlige del af vinduet har udefineret indhold, sender hændelsen en besked til klienten om, at vinduets indhold skal tegnes igen.
Hvert vindue har et tilknyttet sæt attributter, såsom vinduets geometri (størrelse og position), baggrundsbilleder, om det ønskes gemt i hjælpehukommelsen osv. Protokollen indeholder anmodninger til klienten om at kontrollere og ændre vinduets attributter .
Windows kan være InputOutput eller InputOnly. Vinduer af den første slags kan vises på skærmen og bruges til tegning. Den anden slags vinduer vises ikke på skærmen, de bruges kun til at modtage input.
Den dekorative kant og titellinje (eventuelt inklusive knapper), der almindeligvis ses omkring vinduer, er oprettet af vindueshåndteringen , ikke af klienten, der opretter vinduet. Vindueshåndteringen administrerer også input, der er knyttet til disse elementer, såsom vinduesstørrelse, når brugeren klikker og trækker vinduesrammen. Klienter arbejder normalt i et vindue, de oprettes uden at tage højde for ændringer foretaget af vinduesadministratoren. Overvej også de vinduesadministratorer, der erstatter det almindelige overordnede rodvindue for vinduer på øverste niveau. De fleste vinduesadministratorer gør dette nu. Fra den underliggende protokols synspunkt er vindueshåndteringen en klient ligesom andre applikationer.
Information om vinduet kan fås ved at køre programmet xwininfo. Når det køres fra kommandolinjen med argumentet --tree, viser dette program træet af undervinduer fra vinduet sammen med deres identifikatorer og geometridata.
Bitmapbilledet gemmes i serverens hukommelse, det vises ikke på skærmen, men kan tegnes helt eller delvist i vinduet. Indholdet af et vindue kan gemmes som en bitmap. Dette giver mulighed for dobbelt buffering. Grafikoperationer, der er relevante for Windows, kan også anvendes til bitmaps.
Vinduer og bitmaps kaldes tegneområder. Indholdet af tegneområderne gemmes på serveren. Klienten kan sende en anmodning om at overføre indholdet af området fra serveren til klienten eller omvendt.
Klienten kan anmode om flere grafikoperationer, såsom at rydde et område, kopiere et område til et andet, tegne punkter, linjer, rektangler og tekst. Udover rydning kan alle operationer udføres på alle tegnearealer.
De fleste anmodninger om grafiske operationer inkluderer en grafisk kontekst, en datastruktur, der indeholder parametre for grafiske operationer. Grafikkonteksten inkluderer forgrundsfarve, baggrundsfarve, tekstskrifttype og andre indstillinger. Når du anmoder om grafikoperationer, inkluderer klienten en grafikkontekst. Ikke alle grafikkontekstindstillinger påvirker handlingen: for eksempel påvirker skrifttypen ikke tegningen af linjen.
Kerneprotokollen kræver brug af server-side skrifttyper. Disse skrifttyper gemmes som filer, og serveren tilgår dem direkte gennem det lokale filsystem eller over netværket ved hjælp af et andet program kaldet en skrifttypeserver. Klienten kan anmode om en liste over tilgængelige skrifttyper på serveren, kan anmode om at uploade en skrifttype til serveren (hvis en sådan skrifttype ikke allerede er på serveren), eller uploade en skrifttype (hvis den ikke bruges af andre klienter) på serveren. Klienten kan anmode om information om skrifttypen (f.eks. stigningen af skrifttypen) og den plads, der optages af en bestemt linje, når den tegnes i en bestemt skrifttype.
Skrifttypenavne på niveauet af X Window-hovedprotokollen er vilkårlige strenge. Den logiske skrifttypekonvention for X angiver præcis, hvordan skrifttyper skal navngives i henhold til deres attributter. Disse konventioner specificerer også værdierne af yderligere egenskaber, som skrifttyper kan have.
Programmet xlsfonts viser en liste over skrifttyper, der er gemt på serveren, viser skrifttypesymboler og giver brugeren mulighed for at vælge et skrifttypenavn at indsætte i et andet vindue.
Skrifttypegengivelse på serversiden betragtes nu som forældet, og de fleste klienter (GTK, Qt) udfører allerede skrifttypegengivelse. For at gengive skrifttyper bruger klienter Xft- eller cairo-bibliotekerne og XRender-udvidelserne. Kerneprotokolspecifikationen beskriver ikke skrifttypegengivelse på klientsiden.
Alle data om vinduer, bitmaps, skrifttyper og andre objekter gemmes på serveren. Klienten gemmer identifikatorerne (unikke numre) for disse objekter og bruger dem som navne, når de interagerer med serveren. For eksempel sender en klient, der ønsker at oprette et vindue, en anmodning til serveren om at oprette et vindue med det givne ID. Identifikationen kan bruges af klienten senere, for eksempel til at anmode om at tegne streger på vinduet. Følgende objekter er gemt på serveren og er tilgængelige for klienten via digitale identifikatorer:
Disse objekter kaldes ressourcer. Når en klient anmoder om oprettelse af en af disse ressourcer, angiver den også dens identifikator . For at oprette et nyt vindue angiver klienten f.eks. både vinduets attributter (forældre, bredde, højde og så videre) og en identifikator, der er knyttet til vinduet.
Identifikatorer er 32-bit heltal , hvis tre mest signifikante bit altid er nul. Hver klient har sit eget sæt id'er, der kan bruges til at oprette nye ressourcer. Dette sæt udsendes af serveren i en bekræftelsespakke (pakken sendt til klienten for at angive, at forbindelsen er blevet accepteret) og er repræsenteret som to numre. Klienter vælger identifikatorer fra dette sæt på en sådan måde, at forskellige objekter har forskellige identifikatorer.
Når en ressource er oprettet, kan dens ID bruges af klienten i anmodninger til serveren. Nogle handlinger påvirker disse ressourcer (f.eks. en anmodning om at flytte et vindue), andre anmodninger om ressourcer, der er gemt på serveren (f.eks. anmodninger om vinduesattributter).
Identifikatorer er unikke ikke kun for klienten, men også for serveren. Så to vinduer kan ikke have det samme ID, selvom de er oprettet af to forskellige klienter. En klient kan få adgang til ethvert objekt ved hjælp af dets identifikator (selv en anden klients objekt).
Som et resultat kan to klienter, der er tilsluttet den samme server, bruge den samme identifikator til at henvise til den samme ressource. For eksempel, hvis en klient opretter et vindue med ID 0x1e00021 og sender det nummer 0x1e00021 til en anden applikation (på enhver tilgængelig måde, såsom at gemme det nummer i en fil, der også er tilgængelig for andre applikationer), så kan den anden applikation køre på den samme vindue.. Denne funktion bruges for eksempel af X Window-versionen af Ghostview -programmet : dette program opretter et underordnet vindue, gemmer dets identifikator i en miljøvariabel og kalder Ghostscript , som tegner indholdet af PostScript -filen og viser det i denne vindue [8].
Ressourcer ødelægges typisk, efter at den klient, der oprettede dem, lukker forbindelsen til serveren. Inden forbindelsen lukkes, kan klienten dog sende en anmodning til serveren og bede dem om ikke at ødelægge dem.
Hændelser er pakker sendt af serveren til klienten med en besked om, at det, klienten forventede, skete. For eksempel sendes en hændelse, når brugeren trykker på en tast eller trykker på en museknap. Hændelser kan bruges til mere end blot input: hændelser sender for eksempel en indikation om at oprette nye undervinduer i et givet vindue.
Hver begivenhed er knyttet til et vindue. For eksempel, hvis brugeren klikker med musen, vil hændelsen henvise til det vindue, som markøren var over på tidspunktet for klikket. Hændelsespakken vil indeholde dette vindues ID.
Klienten kan anmode serveren om at sende en begivenhed til en anden klient. Dette bruges til at organisere interaktion mellem klienter. En sådan hændelse genereres for eksempel, når en klient anmoder om valgt tekst og sendes af serveren til den klient, der ejer vinduet med den valgte tekst.
En hændelse Exposeafsendes af serveren, hvis billedet af klientens vinduesområde er blevet ryddet fra hukommelsen, og vinduet bliver synligt. Vinduesbilledet slettes fra hukommelsen, hvis vinduet blev minimeret, dækket af et andet vindue og i andre tilfælde.
De fleste begivenhedstyper sendes kun til klienten, hvis de tidligere har erklæret interesse for dem. For eksempel kan en klient være interesseret i tastaturbegivenheder, men ikke musebegivenheder. På trods af dette videregives nogle typer begivenheder til kunder, selvom de ikke specifikt har bedt om dem.
Klienten vælger de nødvendige hændelsestyper ved at indstille en speciel vinduesattribut - hændelsesmasken. For at begynde at tegne indholdet af et vindue, skal klienten f.eks. modtage Expose. Serveren sender dog kun denne hændelse, hvis klienten har indstillet den passende bit i vinduets hændelsesmaske.
Forskellige klienter kan anmode om begivenheder fra det samme vindue. De kan endda indstille forskellige begivenhedsmasker i det samme vindue. For eksempel kan én klient kun anmode om tastaturbegivenheder, mens en anden kun anmoder om musebegivenheder. Der er dog flere typer arrangementer, som kun kan leveres til én kunde. Disse er især hændelser med museklik og nogle ændringer relateret til vinduesstyring.
xev- et program, der viser begivenheder i forhold til vinduet. Navnlig xev -id WIDforespørger kommandoen alle mulige hændelser vedrørende vinduet med identifikatoren WIDog udskriver dem.
Det følgende er et eksempel på en mulig interaktion mellem en server og et program, der opretter et vindue med et sort boksbillede og afslutter dets tastetryk. I dette eksempel sender serveren ikke noget svar, fordi klienten sender en anmodning, der ikke genererer svar. Disse forespørgsler kan generere fejl.
Hvis et vindue overlapper et andet vindue og ikke overlapper det igen, forudsat at backing-butikken ikke administreres, så:
På protokolniveau er en farve repræsenteret af et 32-bit usigneret heltal kaldet pixelværdi . Følgende elementer deltager i farvegengivelsen:
I det enkleste tilfælde indeholder et farvekort en RGB-treklang i en streng. pixelværdi xer den xte række i tabellen. Hvis klienten kan ændre indtastningerne i farvekortet, identificeres visningen med den visuelle klasse PseudoColor . Den visuelle klasse StaticColorligner, men klienten kan ikke ændre indtastninger i farvetabellen.
I alt 6 visuelle klasser er tilgængelige. Hver er defineret af en anden måde at repræsentere en RGB-triade med en pixelværdi. PseudoColorog StaticColorde to første. De næste to - GrayScaleog StaticGray, adskiller sig ved, at de kun viser grå nuancer.
De resterende to visuelle klasser adskiller sig fra ovenstående ved, at de ikke bruger pixelværditriaden, men bruger tre forskellige tabeller for røde, grønne og blå intensitetsværdier.
Ifølge repræsentationen af farver konverteres pixelværdi til RGB-triade i følgende tilfælde:
Denne mekanisme kræver, at farvekortet er sammensat af tre separate tabeller, hver for en af de primære farver. Resultatet af transformationen er yderligere tre intensitetsværdier. De visuelle klasser, der bruges af denne visning, er: DirectColoreller TrueColor, der adskiller sig ved, at klienten kan ændre farvekortet eller ej.
Alle disse seks mekanismer til at repræsentere farver med pixelværdi kræver nogle yderligere parametre for at fungere. Disse muligheder er samlet i en visuel type , der indeholder den visuelle klasse og resten af mulighederne for at repræsentere farver. Hver server har et begrænset antal installerede visuelle typer, og hver type er forbundet med en numerisk identifikator. Identifikatorerne er 32-bit heltal uden fortegn, men er ikke nødvendigvis forskellige fra ressource- eller atomidentifikatorer.
Når en forbindelse accepteres fra klienten, indeholder bekræftelsespakken, der sendes til serveren, en sekvens af blokke, der hver indeholder information om én skærm. For hver skærm indeholder relative blokke en liste over andre blokke, hver relativ blok definerer farvedybden, der understøttes af skærmen. For hver farvedybde indeholder denne liste de visuelle typer. Som et resultat er hver skærm forbundet med nogle mulige farvedybdeværdier, og hver farvedybde på hver skærm er forbundet med mulige visuelle typer. Disse visuelle typer kan bruges til andre skærme og forskellige farvedybder.
For hver visuel type indeholder bekræftelsespakken begge disse identifikatorer og de faktiske indholdsparametre (visuel type osv.) Klienten gemmer denne information, da den ikke vil være i stand til at anmode om denne information igen i fremtiden. Derudover kan klienter ikke ændre eller oprette nye visuelle typer. Anmodninger om at oprette et nyt vindue inkluderer farvedybden og visuel type-id til visning af farverne i det pågældende vindue.
Farvekort bruges uafhængigt af den hardware, der styrer skærmen (det vil sige, at videokortet kan bruge en palet (farvetabel). Servere bruger farvekort, selvom hardwaren ikke bruger en palet. Når hardwaren bruger paletter, kan et begrænset antal farvekort installeres. Især er farvekort indstillet, når hardwaren viser ensartede farver. Klienten kan anmode serveren om at installere et farvekort. Dette kan dog kræve fjernelse af et andet farvekort: Effekten af at bruge det fjernede farvekort vil være et billede med forkerte farver, en dobbeltfarvet burst-effekt eller farver med høj intensitet. Dette problem kan løses ved at bruge standard farvekort. Disse er farvekort med foruddefinerede associationer mellem pixelværdier og farver. Takket være denne kvalitet kan standardfarvekort bruges til forskellige applikationer.
Oprettelse af farvekort er underlagt ICCCM-aftalen. Standardfarvekort er defineret af ICCCM og Xlib-specifikationen.
En del af X-farvesystemet er X-farvestyringssystemet (xcms). Dette system dukkede op med X11R6 Release 5 i 1991. Dette system er indeholdt i form af flere yderligere Xlib-funktioner, der findes i en række funktioner, hvis navne begynder med Xcms. Systemet definerer enhedsuafhængige farveskemaer, der allerede kan konverteres til enhedsafhængige RGB-systemer. Systemet indeholder Xlib Xcms*-funktionerne samt X Device Color Characterization Convention (XDCCC), som beskriver, hvordan forskellige enhedsuafhængige farvesystemer konverteres til enhedsafhængige RGB-farvesystemer. Dette system understøtter CIEXYZ, xyY, CIELUV og CIELAB farvesystemer samt TekHVC.
| X vinduessystem | |
|---|---|
| Arkitektur |
|
| Vinduesbestyrere |
|
| Udvidelser |
|
| Implementeringer | |
| Standarder | |
| Ansøgninger |
|