LX Window System core protocol (protocollo principale di X Window System) 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-XRFC 1013Grant Edwards. An Introduction to X11 User Interfaces è il protocollo base dell'X Window System, che è un sistema (che lavora in rete) di gestione delle finestre per bitmap display usato per creare interfacce grafiche utente in sistemi Unix, Unix-like e altri sistemi operativi. L'X Window System è basato su un modello client-server: un singolo server controlla l'hardware diinput/output, come lo schermo, la tastiera e il mouse; ogni applicazione (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 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 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 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 Jim Gettys. Open Source Desktop Technology Road Map come le specifiche ICCCM e freedesktop.org e sono tipicamente definite automaticamente dall'uso di un dato insieme di widget.
Panoramica
La comunicazione fra server e i client avviene mediante lo scambio di pacchetti attraverso un 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.
I pacchetti di richiesta sono numerati sequenzialmente dal server non appena vengono ricevuti: la prima richiesta da un client viene numerata 1, la seconda 2, ecc. I 16 bit meno significativi del numero di sequenza di una richiesta vengono inclusi negli eventuali pacchetti di risposta ed errore generati dalla richiesta. Sono inclusi anche nei pacchetti di evento per indicare il numero di sequenza della richiesta che il server sta processando attualmente o ha appena finito di processare.
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 bottoni, menu, 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 (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.
Non è sempre garantito che il contenuto di una finestra venga preservato nel tempo. In particolare, il contenuto di una finestra può essere distrutto quando una finestra viene spostata, ridimensionata, coperta da altre finestre, e in generale resa totalmente o parzialmente non visibile. In particolare, il contenuto viene perso se l'X server non mantiene una backing store (memoria del passato) del contenuto della finestra. Il client può richiedere alla backing store che una finestra venga mantenuta, ma non c'e l'obbligo da parte del server di farlo. Perciò, i client non possono assumere che la backing store venga mantenuta. Se una parte visibile di una finestra ha un contenuto non specificato, viene inviato un evento per notificare che il contenuto della finestra deve essere ridisegnato.
Ogni finestra ha un insieme di attributi associato, tipo la geometria della finestra (dimensione e posizione), l'immagine di sfondo, se è stata fatta una richiesta alla backing store per essa, ecc. Il protocollo comprende richieste da parte dei client per ispezionare e cambiare gli attributi di una finestra.
Le finestre possono essere di InputOutput o InputOnly. 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.
I dati su una finestra possono essere ottenuti eseguendo il programma xwininfo. Passandogli l'argomento -tree, questo programma mostra l'albero delle sotto finestre di una finestra, assieme ai loro identificatori e dati sulla geometria.
Pixmap (mappe di pixel) e drawable (oggetti disegnabili) Una pixmap è una regione di memoria che può essere usata per disegnare. A differenza delle finestre, le pixmap non sono automaticamente disegnate sullo schermo. Comunque, il contenuto di una pixmap (o una parte di essa) può essere trasferito ad una finestra o viceversa. Questo permette l'uso di tecniche tipo il double buffering. La maggioranza delle operazioni grafiche che può essere eseguita su una finestra può anche essere fatta su una pixmap.
Le finestre e le pixmap sono entrambe chiamate drawables (oggetti disegnabili), e i loro contenuti risiedono nel server. Un client può comunque richiedere che il contenuto di un drawable venga trasferito dal server al client o viceversa.
Contesti grafici e fonts Il client può richiedere un certo numero di operazioni grafiche, come pulire un'area, copiare un'area in un'altra, disegnare punti, linee, rettangoli e testo. A parte la pulizia, tutte le altre operazioni sono fattibili su tutti gli oggetti, sia finestre che pixmap.
La maggioranza di richieste di operazioni grafiche comprende un graphic context (contesto grafico), che è una struttura che contiene i parametri delle operazioni grafiche. Un contesto grafico include un colore di primo piano (foreground), un colore di sfondo (background), il font del testo e altri parametri grafici. Quando richiede un'operazione grafica, il client include un contesto grafico. Non tutti i parametri del contesto grafico sono necessari per l'operazione: per esempio, il font non ha alcun effetto nel disegnare una linea.
Il core protocol specifica l'uso di font lato-server. 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 specificano come i font dovrebbero essere nominati in accordo con i loro attributi. Queste convenzioni specificano anche i valori delle proprietà opzionali che possono essere assegnate ai font.
Il programma xlsfonts stampa la lista dei font immagazzinati nel server. Il programma xfontsel 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.Matthieu Herrb and Matthias Hopf. New Evolutions in the X Window System. Tali font sono renderizzati dal client, non dal server, con il supporto delle librerie grafiche Xft o cairo e l'estensione XRender. Nessuna specifica è data sui font lato-client nel core protocol.
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:
Window Pixmap Font Colormap (una tavola dei colori, descritta sopra) Graphic context (Contesto grafico)