X Window System core protocol: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m smistamento lavoro sporco e fix vari |
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 |
||
| (3 versioni intermedie di 3 utenti non mostrate) | |||
Riga 5:
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 (la sua pubblicazione corrente X11 comparve nel settembre 1987). I suoi progettisti [[Bob Scheifler]] e [[Jim Gettys]] stabilirono come primi principi che il suo core protocol doveva "creare meccanismi e non politiche". Come risultato di ciò, il procollo principale non specifica l'interazione fra i client e tra client e utente. Queste interazioni sono l'oggetto di specifiche separate <ref name="gett">Jim Gettys. [https://freedesktop.org/~jg/roadmap.html Open Source Desktop Technology Road Map] {{webarchive|url=https://web.archive.org/web/20031124214515/http://freedesktop.org/~jg/roadmap.html |data=24 novembre 2003 }}</ref> come le specifiche [[ICCCM]] e [[freedesktop.org]] e sono tipicamente definite automaticamente dall'uso di un dato insieme di [[widget (informatica)|widget]].
== Panoramica ==
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 identificatori che i parametri attuali relativi contenuti (visual class, ecc.) Il client salva queste informazioni, dato che non può richiederle in seguito. In più, i client non possono cambiare o creare nuove visual type. Le richieste per la creazione di una nuova finestra comprendono la profondità e l'identificatore della visual type da usare per rappresentare i colori della finestra stessa.
Riga 158:
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>{{Cita web |url=http://insar.stanford.edu/~lharcke/programming/Xcms/ |titolo=The X Color Management System (Xcms)<!-- Titolo generato automaticamente --> |accesso=18 maggio 2009 |urlarchivio=https://web.archive.org/web/20111005224650/http://insar.stanford.edu/~lharcke/programming/Xcms/ |urlmorto=sì }}</ref>,<ref>[http://tronche.com/gui/x/xlib/color/ Xlib Programming Manual: Chapter 6: Color Management Functions<!-- Titolo generato automaticamente -->]</ref>
== Atomi ==
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]].
Riga 257:
# 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 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.
| |||