Dopo la lunga parentesi in cui abbiamo parlato dell'interfaccia di una
applicazione, torniamo a parlare dell'interfaccia dell'intero sistema o
ambiente di lavoro.
Abbiamo visto che l'ambiente di lavoro e' organizzato secondo la metafora
della scrivania o desktop.
Il sistema a finestre "implementa" l'ambiente desktop.
Sistema a finestre: sistema software che poggia sul sistema operativo e si pone fra le applicazioni (dotate di interfaccia utente) ed i dispositivi di I/O per gestire l'interazione fra utente ed applicazioni.
NOTA: qui per applicazione intendiamo applicazione dotata di interfaccia utente e la intendiamo compresa la sua interfaccia.
Il WMS gestisce i dispositivi di I/O per conto delle applicazioni (nota: qui intendiamo l'applicazione compresa la sua interfaccia).
Per fare questo il WMS:
Organizza lo schermo a finestre. Ogni finestra e' un'area autonoma di I/O, come uno schermo nello schermo. Permette di catturare l'input e produrre l'output delle diverse applicazioni, o sotto-parti di una stessa applicazione, senza che queste interferiscano.
Fornisce un'interfaccia di programmazione (API = Application Program Interface), libreria software che il programmatore puo' usare per accedere ai servizi del WMS. La libreria ha funzioni per usare le risorse a disposizione (finestre, testo, grafica) e ricevere l'input dell'utente.
Di solito tra il WMS e l'applicazione finale dotata di interfaccia si colloca un toolkit per interfacce utente. L'implementazione interna del toolkit usa la API del WMS e definisce una sua API. L'applicazione finale usa la API del toolkit, che e' di livello piu' alto di quella del WMS. D'altra parte e' possibile scrivere l'interfaccia di un'applicazione usando direttamente la API del WMS senza usare un toolkit.
Da questo momento in poi consideriamo il caso di una applicazione che
comunichi direttamente col WMS (senza usare un toolkit),
e descriviamo come avviene questa comunicazione.
Nel caso si usi un toolkit, la comunicazione col WMS avviene
all'interno del toolkit (quindi trasparente all'applicazione finale),
e serve al toolkit per costruire i dispositivi gia' pronti
che il toolkit stesso poi fornisce all'applicazione finale.
In questo caso la nostra applicazione e' il toolkit.
Meccanismo generale della comunicazione tra WMS, utente ed applicazione:
L'utente compie azioni sui dispositivi di input. In corrispondenza di tali azioni, il WMS genera eventi e li smista alle applicazioni. L'applicazione interpreta l'evento e si comporta di conseguenza.
L'applicazione fa richieste al WMS per ottenere risorse (es: finestre) che gli permettano di fornire l'output all'utente, e per generare l'output usando tali risorse. Le risorse appaiono all'utente sui dispositivi di output come finestre, testo, grafica. L'utente vede cosi' i risultati e il feedback delle proprie azioni.
Evento = pacchetto di informazioni generato dal WMS in seguito ad un'azione dell'utente su dispositivo di input, ed indirizzato ad un'applicazione. Contiene informazioni che descrivono quello che e' successo (tipo di evento + parametri legati al tipo di evento). Esempi:
Risorsa = struttura dati in memoria che corrisponde ad un potenziale strumento di input/output. Esempi: finestra, font, tavolozza di colori, bitmap o pixmap... Applicazioni chiedono risorse al WMS per poter fare I/O.
Richiesta = atto con cui applicazione chiede al WMS che gli sia assegnata una risorsa oppure chiede di usare risorsa gia' assegnatagli.
Finestra = area rettangolare dello schermo che funge da unita' per lo smistamento dell'input/output tra le applicazioni. Ogni evento e' generato in una finestra. In ogni momento c'e' un'unica finestra che ha il focus, le azioni dell'utente generano eventi nella finestra che ha il focus. Tali eventi sono mandati dal WMS all'applicazione che controlla quella finestra.
Finestre qui non sono solo quelle che si stagliano sullo sfondo del desktop.
Sono anche tutte le loro sottoparti dotate di capacita' di I/O gestite in
modo indipendente.
Esempio: in finestra che ha un pannello di sfondo con due bottoni, i bottoni
sono a loro volta finestre, infatti hanno capacita' di interazione
indipendente (sono sensibili a click del mouse, al contrario del pannello di
sfondo in cui si trovano).
Gli eventi del WMS sono eventi elementari, corrispondono ad azioni fisiche sui dispositivi di input (es. pressione di un tasto) e sono di basso livello rispetto a quelli di un toolkit per interfacce utente. Gli eventi di toolkit sono di livello piu' alto, corrispondono a categorie di azioni logiche sulle componenti dell'interfaccia, derivano da interpretazione degli eventi del WMS. Esempio: attivazione di un bottone (evento di toolkit) puo' corrispondere a pressione del mouse oppure a pressione di una shortcut da tastiera (eventi del WMS distinti).
In questa parte consideriamo eventi del WMS.
Le applicazioni dialogano col WMS mediante le funzioni della API del WMS oppure mediante librerie software di piu' alto livello (toolkit per lo sviluppo di interfacce grafiche) implementate sopra la API del WMS.
La libreria API del WMS contiene funzioni di basso livello come:
I toolkit per interfacce grafiche forniscono componenti
di interfaccia gia' pronti da usare, che l'utente puo'
personalizzare, nonche' eventi di piu' alto livello.
Per esempio fornisce bottoni con gia' associata font per
scrivere l'etichetta e sensibilita' all'evento di attivazione,
il programmatore deve solo specificare la stringa da
scrivere sul bottone.
Abbiamo gia' visto come e' fatto un toolkit e che cosa fornisce alle applicazioni. Ora vediamo come e' fatto il WMS e che cosa fornisce a un toolkit (o direttamente ad una applicazione).
Un WMS puo' essere collegato ad una singola piattaforma sulla quale girano tutte le applicazioni che ne fanno uso, oppure avere una architettura distribuita di tipo client/server.
Il client e' quello che ci mette la CPU, il server e' quello che ci mette schermo e dispositivi di input. Il servizio offerto dal server e' la gestione dell'I/O.
NOTA BENE: Qui i ruoli di client e server sono invertiti rispetto ad altri contesti, nel quali come servizio offerto si intende la potenza di calcolo.
Il client invia richieste al server per ottenere nuove risorse (es. finestra) o usare le risorse gia' ottenute (es. scrivere o sulla finestra).
Il server invia al client:
Per inviare le richieste e per riceve le risposte e gli eventi, il client usa le istruzioni della API del WMS.
Comunicazione fra client e server e' asincrona, cioe' client e server non si "aspettano" l'un l'altro:
Risorsa: struttura dati che risiede sul server, allocata,
mantenuta e gestita dal server stesso per conto di uno o piu' client.
Contiene tutte le informazioni relative ad un potenziale strumento
disponibile al client per fare I/O sul server.
Nota: una risorsa corrisponde ad un potenziale strumento di I/O. Es: una finestra nello stato corrente puo' essere mappata (visibile) oppure non mappata (nascosta).
Risorse possono corrispondere a:
Le informazioni memorizzate nella struttura dati dipendono dal suo tipo.
Ogni risorsa ha un identificatore unico che viene
comunicato dal server al client e usato poi dal client per
accedere alla risorsa.
Quando il client richiede al server una nuova risorsa, il server (se puo' soddisfare la richiesta) alloca la risorsa e fornisce al client l'identificatore (link) della risorsa.
Per per agire su una risorsa gia' ottenuta, il client invia richieste al server usando l'identificatore della risorsa come parametro.
Richieste che client puo' inviare e corrispondenti operazioni compiute dal server per soddisfarle: