Paola Magillo, Univestita' di Genova, Corso di Interfacce Utente per Informatica, a.a. 2004-2005.

SISTEMI A FINESTRE

Window Management Systems (WMS)

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.

Che cosa e' un sistema a finestre?

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:

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.

Comunicazione fra utente ed applicazione tramite il WMS

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.

Concetti chiave

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.

Nuovo concetto piu' generale di 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).

Precisazione sul concetto di evento

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.

Ruolo della Application Program Interface (API)

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:

Con questi ingredienti il programmatore puo' implementare, per esempio, una finestra che si comporti come un bottone.

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).

Architettura dei sistemi a finestre

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.

Architettura client/server

Ruoli di client e 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.

Comunicazione fra client e server

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 asincrona

Comunicazione fra client e server e' asincrona, cioe' client e server non si "aspettano" l'un l'altro:

Ne' il server ne' il client bloccano la loro esecuzione: Percio' ci possono essere dei ritardi.

Risorse

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.

Richieste

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: