X Window System core protocol: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m →Atomi: ortografia |
Funzionalità collegamenti suggeriti: 3 collegamenti inseriti. Etichette: Modifica visuale Modifica da mobile Modifica da web per mobile Attività per i nuovi utenti Suggerito: aggiungi collegamenti |
||
| (21 versioni intermedie di 17 utenti non mostrate) | |||
Riga 1:
[[
L''''X Window System core protocol''' (protocollo principale di X Window System) <ref name="sche-gett">Robert W. Scheifler and James Gettys: ''X Window System: Core and extension protocols, X version 11, releases 6 and 6.1'', Digital Press 1996, ISBN 1-55558-148-X</ref><ref name="rfc 1013">RFC 1013</ref><ref name="intr">Grant Edwards. [http://www.visi.com/~grante/Xtut/ An Introduction to X11 User Interfaces] {{webarchive|url=https://web.archive.org/web/20070103060448/http://www.visi.com/~grante/Xtut/ |data=3 gennaio 2007 }}</ref> è il protocollo base dell'[[X Window System]], che è un sistema (che lavora in rete) di gestione delle finestre per [[bitmap]] display usato per creare [[Interfaccia grafica|interfacce grafiche utente]] in sistemi [[Unix]], [[Unix-like]] e altri [[sistema operativo|sistemi operativi]]. L'X Window System è basato su un modello [[client-server]]: un singolo [[server]] controlla l'[[hardware]] di[[input/output]], come lo [[schermo]], la [[Tastiera (informatica)|tastiera]] e il [[mouse]]; ogni applicazione ([[Programma (informatica)|programma]]) agisce come un client, interagendo con l'utente e con gli altri client attraverso il server. Questa interazione è regolata dal X Window System core protocol. Esistono altri [[Protocollo (informatica)|protocolli]] relativi all'X Window System, sia costruiti ''sopra'' l'X Window System core protocol sia come protocolli separati.
Nell'X Window System core protocol si possono inviare solo quattro tipi di pacchetti, in maniera [[Segnale (informatica)|asincrona]], attraverso la rete: richieste, risposte, eventi ed errori. Le ''Richieste'' vengono inviate da un client ad un server per chiedere ti eseguire alcune operazioni (per esempio, creare una nuova finestra) e ritornare indietro i dati che contiene. Le ''Risposte'' sono inviate dal server per fornire tali dati. Gli ''Eventi'' vengono inviati dal server per notificare ai client dell'attività dell'utente o di altre occorrenze che sono interessati a conoscere. Gli ''Errori'' sono pacchetti inviati dal server per notificare ad un client di errori accaduti durante l'elaborazione delle sue richieste. Le richieste possono generare risposte, eventi ed errori; a parte questo, il protocollo non regola l'ordine specifico in cui i pacchetti sono inviati in rete. Esistono alcune estensioni al core protocol, ognuna delle quali aventi le proprie richieste, risposte, eventi ed errori.
L'X Window System fu concepito al [[Massachusetts Institute of Technology|MIT]] nel 1984 (
== Panoramica ==
Riga 11:
La comunicazione fra server e i client avviene mediante lo scambio di pacchetti attraverso un [[Canale (telecomunicazioni)|canale]]. La connessione viene stabilita dal client (nel protocollo non viene specificato come il client viene avviato). Il client invia anche il primo pacchetto, contenente l'[[ordine dei byte]] da usare e informazioni sulla versione del protocollo e il tipo di autenticazione che il client si aspetta che il server usi. Il server risponde con un pacchetto che stabilisce l'accettazione o il rifiuto della connessione, oppure con una richiesta di ulteriore [[autenticazione]]. Se la connessione viene accettata, il pacchetto di accettazione contiene dati per il client da usare nella seguente interazione con il server.
[[
Dopo che la connessione viene stabilita, possono venire scambiati quattro tipi di pacchetto fra client e server nel canale:
# '''Request:''' Il client richiede informazioni dal server o gli chiede di eseguire un'azione.
# '''Reply:''' Il server risponde alla richiesta. Non tutte le richieste generano una risposta.
# '''Event:''' Il server invia un evento al client, per esempio un input da mouse o tastiera o una finestra che è stata mossa, ridimensionata o esposta.
# '''Error:''' Il server invia un pacchetto di errore se una richiesta non è valida. Dato che le richieste vengono accodate, i pacchetti di errore generati da una richiesta potrebbero non essere inviati immediatamente.
I pacchetti di richiesta e di risposta hanno lunghezza variabile, mentre pacchetti di errore ed evento hanno una lunghezza fissata di 32 [[byte]].
Riga 26:
== Finestre ==
Quella che di solito in altre interfacce grafiche utente viene chiamata una finestra, è una ''finestra top-level'' (di primo piano) nell'X Window System. Il termine ''finestra'' è anche usato per finestre che stanno dentro un'altra finestra, in altre parole, ''sotto finestre'' di una ''finestra padre''. Gli elementi grafici tipo [[Button (informatica)|bottoni]], [[Menu (informatica)|menu]], [[Icona (informatica)|icone]], ecc. sono tutti realizzati usando finestre.
[[
Un client può richiedere la creazione di una finestra. Più precisamente può richiedere la creazione di una sotto finestra di una finestra esistente. Le finestre create dai client sono strutturate in un [[Albero (informatica)|albero]] (una gerarchia). La radice di quest'albero è la ''root window'' (finestra radice), che è una finestra speciale creata automaticamente dal server all'avvio. Tutte le altre finestre sono direttamente o indirettamente sotto finestre della finestra radice. Visivamente la finestra radice è larga come tutto lo schermo (anche se potrebbe essere più larga, nel qual caso l'utente può muoversi sull'area visibile), e sta dietro a tutte le altre finestre.
Riga 38:
Le finestre possono essere di <code>InputOutput</code> o <code>InputOnly</code>. Le finestre che possono essere mostrate sullo schermo e usate per disegnare sono del primo tipo. Quelle del secondo tipo non vengono mai mostrate nello schermo; sono utilizzate solo per ricevere input.
[[
La cornice decorativa e la [[barra del titolo]] (che include eventualmente bottoni) che viene vista di solito attorno alle finestre sono create dal [[window manager]], non dal client che crea la finestra. Il window manager gestisce anche gli input relativi a questi elementi, tipo il ridimensionamento della finestra quando l'utente clicca e trascina il bordo della finestra. I client di solito operano all'interno della finestra che hanno creato, a prescindere dai cambiamenti attuati dal window manager. Un cambiamento che un client deve tenere in considerazione è che i [[re-parenting window manager]] (window manager che adottano tutte le finestre, ovvero le rendono loro figlie), quali sono quasi tutti i window manager moderni, cambiano le finestre top-level in finestre che non sono la radice. Dal punto di vista del core protocol, il window manager è un client, con nessuna differenza rispetto alle altre applicazioni.
Riga 56:
Il core protocol specifica l'uso di font lato-server<ref name="font-faq">[http://www.faqs.org/faqs/fonts-faq/part15/ comp.fonts FAQ: X11 Info]</ref>. Tali font sono salvati su file e il server vi accede o direttamente tramite il [[file system]] locale oppure via rete tramite un altro programma chiamato ''font server''. I client possono fare richiesta della lista di font utilizzabili al server e possono richiedere che un font venga caricato (se non lo è già) o scaricato (se non usato da altri client) dal server. Un client può richiedere informazioni generali sul font (per esempio l'[[ascent]] del font) e lo spazio che una data stringa può occupare quando disegnata con un font specifico.
[[
Il nome dei font sono stringhe arbitrarie a livello del X Window core protocol. Le convenzioni [[X logical font description]] <ref name="logi-font">{{Cita web|url= http://www.xfree86.org/current/xlfd.pdf |titolo= X Logical Font Description Conventions |accesso=30 dicembre 2005 |autore= Jim Flowers |coautori= Stephen Gildea |data= 1994 |formato= PDF |
Il programma <code>xlsfonts</code> stampa la lista dei font immagazzinati nel server. Il programma <code>xfontsel</code> mostra i glifi dei font e permette all'utente di selezionare il nome di un font per usarlo in un'altra finestra.
L'uso di font lato-server è attualmente deprecato in favore dei font lato-client.<ref name="herr-hopf">Matthieu Herrb and Matthias Hopf. [
== Risorse e identificatori ==
Tutti i dati relativi alle finestre, pixmaps, font, ecc. sono salvati nel server. Il client conosce gli [[identificatori]] di questi oggetti che usa come nomi quando interagisce con il server. Per esempio, se un client desidera che venga creata una finestra, richiede al server di creare una finestra con un dato identificatore. L'identificatore può essere usato in seguito dal client per le richieste, per esempio, che venga disegnata una stringa nella finestra. Gli oggetti seguenti risiedono nel server sono noti al client attraverso identificatori numerici:
* <code>Window</code>
Riga 82:
Gli identificatori sono unici anche nel server, non solo nel client; per esempio, due finestre non possono avere lo stesso identificatore anche se create da due client diversi. Un client può accedere ad ogni oggetto noto l'identificatore. In particolare, può anche accedere alle risorse create da un altro client, anche se i loro identificatori sono al di fuori dell'insieme di identificatori che loro (i client) possono creare.
Come risultato di ciò, due client connessi allo stesso server possono usare lo stesso identificatore per riferirsi alla stessa risorsa. Per esempio, se un client crea una finestra con identificatore <code>0x1e00021</code> e passa questo numero <code>0x1e00021</code> ad un'altra applicazione (attraverso qualsiasi mezzo utilizzabile, per esempio salvando questo numero in un file che è accessibile anche all'altra applicazione), questa altra applicazione ha la possibilità di operare proprio nella stessa finestra. Quest'possibilità viene sfruttata per esempio dalla versione X Window di [[Ghostviwe]]: questo programma crea una sotto finestra, salvando il suo identificatore in una [[variabile d'ambiente (Unix)|variabile d'ambiente]] e chiama [[Ghostscript]]; questo programma disegna il contenuto del file [[PostScript]] da mostrare in questa finestra.<ref name="ghos-inte">[
Le risorse sono normalmente distrutte quando il client che le ha create chiude la connessione col server. Comunque, prima di chiudere la connessione, un client può richiedere al server di non distruggerle.
Riga 96:
L'evento <code>Expose</code> viene inviato quando un'area di una finestra dal contenuto non visibile diventa visibile. Il contenuto di una finestra potrebbe venir distrutto in alcune condizioni, per esempio, se la finestra è coperta e il server non sta mantenendo la backing store. Il server genera un evento <code>Expose</code> per notificare al client che una parte della finestra deve essere disegnata.
[[
La maggior parte di tipi di eventi vengono inviati solo se il client ha mostrato interesse in loro in precedenza. Questo perché i client potrebbero essere interessati solo ad alcuni tipi di eventi. Per esempio, un client potrebbe essere interessato ad eventi relativi alla tastiera ma non a quelli relativi al mouse. Alcuni tipi di eventi sono comunque inviati ai client anche se non ne hanno fatto specificatamente richiesta.
Riga 130:
== Colori ==
A livello di protocollo, un colore è rappresentato da un intero senza segno a 32-bit chiamato ''pixel value''. I seguenti elementi influenzano la [[rappresentazione dei colori]]:
# la [[color depth]] (profondità del colore)
Riga 150:
Questi sei meccanismi per la rappresentazione dei colori con i pixelvalue richiedono tutti per funzionare qualche paramentro addizionale. Questi parametri sono collezionati in una ''visual type'', che contiene una visual class e altri parametri della rapparesentazione dei colori. Ogni server ha un insieme fisso di visual type, ognuna associata ad un identificatore numerico. Questi identificatori sono interi senza segno a 32-bit ma non sono necessariamente diversi dagli identificatori di risorse o atomi.
Quando la connessione da un client viene accettata, il pacchetto di accettazione inviato dal server contiene una sequenza di blocchi, ognuno contenente informazioni su un singolo schermo. Per ogni schermo, il blocco relativo contiene una lista di altri blocchi, ognuno dei quali relativo ad una specifica color depth (profondità del colore) supportata dallo schermo. Per ogni profondità, questa lista contiene una lista di visual type. Come risultato di ciò, ogni schermo è associato ad un numero di possibili profondità, e ogni profondità di ogni schermo è associato a
Per ogni visual type, il pacchetto di accettazione contiene sia gli
Le colormap sono usate a prescindere dal fatto che l'hardware che controlla lo schermo (ad esempio una [[scheda grafica]]) usa una [[Tavolozza (informatica)|palette]], che è una tavola che viene anche usata per rappresentare i colori. I server usano colormap anche se l'hardware non sta usando una palette. Ogni volta che l'hardware usa una palette, può essere installato solo un numero limitato colormap. In particolare, una colormap viene installata quando l'hardware può mostrare i colori in accordo con essa. Un client può
La creazione di colori è regolata dalla convenzione [[ICCCM]]. Le colormap standard sono regolate dal [[ICCCM]] e dalle specifiche [[Xlib]].
Una parte del sistema dei colori di X è la ''X Color Management System (xcms)'' (sistema di gestione del colore di X). Questo fu introdotto con X11R6 Release 5 nel 1991. Questo sistema consiste di diverse funzionalità addizionali in xlib, che si trova nella serie di funzioni di Xcms*. Questo sistema definisce schemi di colore ''device independent'' (indipendenti dal dispositivo) che possono essere convertiti in sistemi RGB dipendenti dal dispositivo. Il sistema consiste di funzioni di xlib Xcms* e, come nella X Device Color Characterization Convention (XDCCC) che descrive come convertire i vari sistemi di colori indipendenti dal dispositivo in sistemi di colore RGB dipendenti dal dispositivo. Questo sistema supporta [[CIE XYZ]], xyY, L *u*v e L *a*b così come il TekHVC colour systems.<ref>
== Atomi ==
Riga 181:
Le proprietà sono usate principalmente per la comunicazione fra client. Per esempio, la proprietà chiamata <code>WM_NAME</code> (la proprietà nominata dall'atomo a cui è associata la stringa <code>"WM_NAME"</code>) è usata per salvare il nome per la finestra; i gestori di finestre di solito leggono questa proprietà e visualizzano il nome della finestra nella barra del titolo.
Alcuni tipi di comunicazione inter-client usano proprietà della finestra radice. Per esempio, in accordo con la specifica [[freedesktop]] window manager <ref name="free-desk">[
</ref>, i gestori di finestre dovrebbero salvare l'identificatore della finestra correntemente attiva nella proprietà di nome <code>_NET_ACTIVE_WINDOW</code> della finestra radice. Le [[X resources]], che contengono i parametri dei programmi, sono anch'esse salvate in proprietà della finestra radice; In questo modo, tutti i client possono accedere ad esse, anche se girano in computer differenti.
Riga 188:
== Mappings (Mappature) ==
[[
In X Window System, ogni singolo tasto è associata ad un numero nell'intervallo 8-255 chiamato ''keycode'' (codice tasto). Un keycode identifica solo un tasto, non un particolare carattere o termine (ad esempio "Page Up") fra quelli che potrebbero essere raffigurati nel tasto. Ognuno di questi caratteri o termini viene invece identificato da un ''keysym''. Mentre un keycode dipende solo dal tasto appena premuto, un keysym potrebbe dipendere, per esempio, dalla pressione o meno del tasto Shift o qualche altro modificatore (Ctrl, Alt, ecc.).
Quando un tasto viene premuto o
# il keycode del tasto premuto
# lo stato corrente dei modificatori (Shift, Control, ecc.) e dei bottoni del mouse
[[
Il server invia quindi un keycode e lo stato dei modificatori senza cercare di tradurlo in uno specifico carattere. È responsabilità del client fare questa conversione. Per esempio, un client potrebbe ricevere un evento che stabilisce che un dato tasto è stato premuto mentre il modificatore Shift era premuto. Se questo tasto normalmente genererebbe il carattere "a", il client (e non il server) associa questo evento al carattere "A".
Riga 207:
Per ognuno degli otto modificatori, il server X mantiene una lista di keycode, che lui considera essere modificatori. Ad esempio, se la lista del primo modificatore ("Shift") contiene il keycode <code>0x37</code> allora il tasto che produce il keycode <code>0x37</code> è considerato un tasto modificatore "di tipo shift" dal server X.
La lista che mappa i modificatori è mantenuta dal server X ma può essere cambiata da ogni client. Per esempio, un client può richiedere che il tasto "F1" venga aggiunto alla lista dei modificatori di tipo "Shift". Da qui in avanti, questo tasto si comporta come un altro modificatore di tipo Shift. Comunque, il keycode corrispondente a F1 viene comunque generato quando questo tasto viene premuto. Come risultato di ciò, F1 opera come faceva prima (ad esempio, potrebbe venire aperta una finestra di help), ma opera anche come il tasto Shift (premendo "a" in un [[editor di testo]] e assieme F1, verrebbe stampato il carattere "A").
Il server X mantiene e usa una mappatura dei modificatori per i bottoni del mouse. Comunque, i bottoni possono essere solo [[Permutazione|permutati]]. Questo è maggiormente utile per scambiare il tasto destro con quello sinistro per gli utenti [[mancinismo|mancini]].
Il programma <code>xmodmap</code> mostra e cambia mappature di tasti, modificatori e bottoni del mouse.
Riga 215:
== Grabs (Catture) ==
Una ''grab'' è una condizione nella quale tutti gli eventi di mouse o tastiera sono inviati ad un singolo client. Un client può richiedere la cattura di mouse, tastiera o di entrambi: se la richiesta è approvata dal server, tutti gli eventi di mouse/tastiera sono inviati al client che ha richiesto la cattura finché la cattura viene
Quando richiede una grab, un client specifica una ''grab window'' (finestra di cattura): tutti gli eventi sono inviati al client come se fossero relativi alla grab window. Comunque, gli altri client non ricevono gli eventi anche se li hanno selezionati nella grub window. Ci sono due tipi di catture:
; attiva: la cattura ha luogo immediatamente
; passiva: la cattura ha luogo solo quando un viene premuto un tasto o un bottone del mouse specificato in precedenza e termina quando questo viene
[[
Una richiesta di cattura può includere una richiesta di ''freezing'' (congelamento) di tastiera o puntatore. La differenza tra cattura e congelamento è che la cattura cambia il destinatario degli eventi, mentre il congelamento ferma proprio la loro consegna. Quando una periferica è congelata, gli eventi che genera sono salvati in una coda da cui essere consegnati normalmente una volta finito il congelamento.
Riga 237:
== Estensioni ==
[[
Il X Window core protocol fu progettato per essere estensibile. Esso specifica un meccanismo per interrogare le estensioni disponibili e come sono fatti gli eventi, le estensioni, i pacchetti di errore dell'estensione.
Riga 244:
== Autorizzazioni ==
{{
Quando il client inizialmente stabilisce una connessione con il server, il server può replicare o accettando la connessione o rifiutandola o richiedendo un'[[autorizzazione (informatica)|autorizzazione]]. Il core protocol non specifica il processo di autenticazione, che dipende dal tipo di autenticazione usata, a parte che deve finire con l'invio o di un'accettazione o di un rifiuto da parte del server.
Riga 251:
== Xlib e altre librerie client ==
{{
La maggior parte dei programmi client comunicano con il server attraverso la libreria Xlib client. In particolare, la maggior parte di client usa librerie tipo [[X Athena Widgets|Xaw]], [[Motif]], GTK+, o Qt le quali a loro volta usano Xlib per interagire con il server. L'uso di Xlib ha i seguenti effetti:
# Xlib rende i client sincroni per quanto riguarda eventi e risposte:
## le funzioni Xlib che inviano richieste si bloccano finché non ricevono le appropriate risposte, se ne aspettano qualcuna; in altre parole, un client X Window che non usa Xlib può inviare una richiesta al server e dopo fare altre operazioni mentre sta aspettando la risposta, ma un client che usa Xlib può solamente chiamare una funzione Xlib che invia la richiesta e aspetta la risposta, perciò bloccando il client mentre aspetta (a meno che un client non faccia partire un nuovo thread prima di chiamare la funzione);
## mentre il server invia gli eventi [[asincrono|in maniera asincrona]], Xlib salva gli eventi ricevuti dal client in
# Xlib non invia richieste al server immediatamente, ma le salva in una coda, chiamata ''output buffer''; le richieste nell'output buffer sono effettivamente inviate quando:
Riga 264:
## il programma chiede di un evento nella coda degli eventi (per esempio chiamando <code>XNextEvent</code>) e la chiamata si blocca (ad esempio, <code>XNextEvent</code> si blocca se la coda è vuota).
Librerie di più alto livello tipo [[Intrinsics|Xt]] (che è a volte usato da [[X Athena Widgets|Xaw]] e [[
Librerie a basso livello, tipo [[XCB (informatica)|XCB]], forniscono accesso asincrono al protocollo, permettendo un miglior occultamento della latenza.
Riga 270:
== Quello che il procollo principale di X Window System non specifica ==
Il procollo principale di X Window non regola la comunicazione inter-client a non specifica come le finestre sono usate per formare gli elementi visuali comuni in un'interfaccia grafica utente (bottoni, menu, ecc.) Gli elementi dell'interfaccia grafica utente sono definiti dalle librerie client che realizzano [[
La comunicazione inter-client è centrale nelle selezioni, cut buffers r nel trascinamento, che sono metodi usati da un utente per trasferire dati fra una finestra all'altra. Dato che le finestre potrebbero essere controllate da programmi diversi, un protocollo per scambiare questi dati è necessario. La comunicazione inter client è rilevante anche per i [[Window manager]] che sono programmi che controllano la visualizzazione delle finestre e il "look-and-feel" generale di una GUI. Un'altra questione ancora dove la comunicazione inter-client è per certi versi rilevante è quella del session manager.
Riga 280:
== Voci correlate ==
* [[Protocolli e architettura di X Window System]]
== Collegamenti esterni ==
* {{en}}[
* {{
* {{
* {{en}}[ftp://ftp.x.org/pub/X11R7.0/doc/PDF/proto.pdf The X11R7 Protocol Specification]
[[Categoria:X Window System| ]]
| |||