STRUTTURA E FUNZIONAMENTO DI UN'INTERFACCIA UTENTE

Di che cosa parliamo

C'e' l'interfaccia di una particolare applicazione e l'interfaccia generale dell'ambiente di lavoro su una certa macchina, cioe' l'interfaccia del sistema. Qui parliamo del primo caso.

Una interfaccia utente grafica e' costituita da:

• una o piu' finestre
• vari dispositivi (o elementi, o componenti) di interfaccia situati all'interno delle finestre

Alcuni usano il termine componenti di interfaccia per indicare sia le finestre che i dispositivi, altri solo per i dispositivi.

Le finestre intese in questa accezione sono anche chiamate "finestre top-level". In un'altra accezione per finestra si intende qualsiasi area rettangolare dello schermo con caratteristiche di comportamento proprie, quindi anche i vari elementi dentro una finestra sono finestre (ma lo vedremo piu' avanti).

Le finestre

Una finestra ha:

• Bordo o contorno
  Gestito dal window manager (= gestore delle finestre, programma che fa parte dell'interfaccia del sistema e lo vedremo dopo).
  Contiene elementi (decorazioni del window manager) che sono gli stessi, con uguale aspetto grafico e comportamenti uguali per tutte le finestre dell'ambiente di lavoro (barra del titolo, dispositivi di controllo per chiudere, iconificare, portare a tutto-schermo, spostare, redimensionare...).

• Interno o zona di contenuto
  Gestito dall'applicazione a cui la finestra appartiene.
  In genere strutturato (vari elementi -- dispositivi -- con caratteristiche grafiche e comportamentali diverse)

Non tutte le finestre hanno l'insieme completo delle decorazioni. In finestre temporanee (es. per messaggio di errore) possono mancare in parte.

Tipi di finestre

Secondo la classificazione di MS-windows.

• Finestre di applicazione
• Finestre di documento
• Finestre di dialogo

Finestra di applicazione

Appare quando l'utente lancia un programma.
Ha l'insieme completo delle decorazioni del window manager.
In genere ha una barra di menu' che mostra le varie funzionalita' dell'applicazione (es: file, edit, view...).

Finestra di documento

E' associata ad una finestra di applicazione. E' relativa ad un file (documento) aperto nell'ambito dell'applicazione.
Ci possono essere piu' finestre di documento associate ad una stessa finestra di applicazione.
Ha un titolo col nome del documento, e in genere anche le altre decorazioni (ma... vedi qui sotto...).

Le finestre di documento dello stesso programma possono essere gestite in vari modi:

• Finestre apparentemente indipendenti, ognuna replica l'aspetto della finestra principale. Ma il programma e' stato lanciato una sola volta e solo la chiusura dell'ultima finestra (=dell'ultimo documento) ne provoca la terminazione -- non sono piu' istanze dello stesso programma!
  (esempio: acrobat reader)
• La finestra principale contiene solo i comandi di base (open, exit...), ciascuna finestra di documento ha i suoi comandi per agire sul particolare file.
  (esempio: gimp)
• La finestra principale contiene al suo interno le secondarie simulando uno "schermo" in cui queste possono essere spostate, dimensionate, iconificate, espanse...
  (esempio" MS-Word)
• La finestra principale e' organizzata a scheda, ciascun documento aperto occupa una scheda (tab).
  (esempio: internet browser)

Finestra di dialogo

Finestra transitoria attraverso la quale l'applicazione presenta messaggi e/o richiede input all'utente. E' pensata per rimanere sullo schermo solo per poco tempo.
Puo' non avere tutte le decorazioni del window manager (es. puo' non avere senso spostarla o redimensionarla).
Contiene sempre bottoni (di solito in basso) per chiudere la finestra. A seconda dello scopo del dialogo: Ok, Ok/Cancel, Yes/No/Cancel, ecc.
Le dimensioni di una finestra di dialogo sono abbastanza piccole per enfatizzare la sua natura di finestra supplementare.

Esempi di finestre di dialogo:

• Finestre di messaggi (es. notifica di errore)
• Finestre informative (es. con autori, copyright, numero della versione del programma...)
• Finestre per la selezione di file (permettono di navigare nel file system alla ricerca del file da aprire/da salvare/ecc.)
• Finestre di stampa (per impostare le opzioni di stampa di un documento: numero di copie, quali pagine, ecc.).

Una finestra di dialogo puo' essere modale o non modale:

• Finestra di dialogo modale rimane la finestra attiva (= quella su cui viene diretto l'input del mouse e della tastiera) e impedisce all'utente di interagire con altre finestre della stessa applicazione finche' l'utente non chiude la finestra di dialogo, premendo uno degli appositi bottoni.
  In genere ha una dimensione fissa, ma puo' essere movibile.

• Finestra di dialogo non modale permette all'utente di proseguire l'interazione con altre finestre della stessa applicazione senza rispondere al dialogo.
  Puo' diventare non piu' la finestra attiva e/o essere oscurata da altre finestre.

Gerarchia di dipendenza delle finestre

Si riferisce a quando una finestra ne invoca (fa apparire) un'altra. Cioe' quando un'azione dell'utente sulla prima finestra provoca la comparsa della seconda finestra.
Si dice allora che la seconda finestra dipende funzionalmente dalla prima.

• Finestra primaria:
  Si apre quando viene lanciata un'applicazione. Le finestre di applicazione sono primarie.
• Finestra secondaria:
  Si apre in seguito ad azioni effettuate dall'utente su un'altra finestra (che puo' essere primaria o secondaria). Le finestre di documento e di dialogo sono secondarie.

Rappresentazione grafica della gerarchia di dipendenza

La gerarchia di dipendenza funzionale si puo' visualizzare sotto forma di un albero o un grafo diretto, dove ogni volta che una finestra B dipende funzionalmente da una finestra A si ha un arco diretto da A verso B. Le finestre primarie non hanno archi entranti.

Vincoli tra finestre primarie e secondarie

Iconificazione di finestra primaria fa sparire le finestre secondarie che da essa dipendono.
De-iconificazione di finestra primaria fa riapparire anche le finestre secondarie.

Chiusura della finestra primaria termina l'applicazione e fa chiudere tutte le finestre secondarie che ha generato.

Dispositivi o componenti di un'interfaccia

Oggetti con aspetto grafico e comportamento (sensibilita' a particolari eventi e capacita' reattive) che "popolano" una finestra e permettono interazione con l'utente.

Sono forniti da una libreria o toolkit per sviluppo di interfacce: pacchetto che fornisce insieme di elementi di interfaccia pronti all'uso e insieme di funzioni (API) per utilizzarli nella costruzione di un'interfaccia.

La libreria fornisce tipi o classi di dispositivi. Ciascun tipo ha proprie caratteristiche di aspetto / comportamento (es. bottoni, campi di input testuale...) in parte personalizzabili, e possibilita' di inserire comportamenti aggiuntivi.

Esempio: un bottone e' un'area rettangolare sensibile al click del mouse. Posso personalizzarlo scegliendo dimensioni, colore, font della scritta... Ha predefinito il comportamento di evidenziarsi quando viene cliccato, posso aggiungere quello di chiamare una certa funzione applicativa (es. salvare il file corrente).

La libreria / toolkit fornisce:

• un insieme di classi di dispositivi
• un insieme di funzioni (API, application program interface) che servono al programmatore per scrivere il codice di un'interfaccia: creare dispositivi, personalizzarli, posizionarli, aggiungervi comportamenti...

Nota:
Interfaccia Utente (IU) o User Interface (UI) = interfaccia del programma applicativo verso l'utente.
Application Program Interface (API) = interfaccia del toolkit verso il programma applicativo, si tratta dell'interfaccia fra due strati SW.
Il programma applicativo usa il toolkit (tramite la sua API) per costruire la propria IU verso l'utente. L'utente poi usa il programma applicativo tramite la sua IU cosi' costruita.

Programmazione guidata da eventi
(o Event-driven programming) rivisitata

+------+         azione su                        +------------+     +--------+
|      |--(1)--> dispositivo --(2)-->  evento --->|    (3)     |     | (3bis) |
|      |         di input                         |interfaccia |     |        |
|utente|                                          |della       |<--->|appli-  |
|      |         feedback su          reazione    |applicazione|     |cazione |
|      |<--(5)-- dispositivi <--(4)-- (cambio <---|            |     |        |
+------+         di output            di stato)   +------------+     +--------+

(1) L'utente compie azioni sui dispositivi di input (mouse, tastiera).

(2) Le azioni sono tradotte in eventi. Evento = pacchetto di informazioni che descrive che cosa e' avvenuto. Qui la libreria / toolkit esegue gia' una parziale interpretazione delle azioni. Esempi:

• azione click del mouse a seconda delle circostanze puo' dare evento di azionamento (se su bottone), evento di presa del focus (se su campo di input testuale) ecc.
• un evento puo' condensare piu' azioni (es. doppio click)

(3) L'evento viene elaborato dal codice dell'interfaccia, per decidere che cosa fare (come reagire). L'elaborazione puo' avvenire a due livelli:

1. a livello di libreria / toolkit per i comportamenti predefiniti
2. a livello di codice scritto dal programmatore per i comportamenti aggiuntivi (personalizzati)

(4) La reazione (avvenuto cambio di stato) viene comunicata all'utente come feedback sui disposiviti di output (schermo, altoparlante).

(5) L'utente riceve il feedback e in base a questo decidera' la prossima azione...

Esempio

Applicazione per cambiare il contrasto di una foto. L'interfaccia mostra la foto e un potenziometro (o slider) con cursore mobile.

Evento di aggancio / rilascio del cursore da parte dell'utente (premendo / rilasciando il mouse sopra) e' gestito a livello libreria.
Evento di movimento del cursore (trascinandolo a mouse premuto) e' gestito:

• a livello libreria dando come feedback il disegno del cursore alla nuova posizione
• a livello di codice scritto dal programmatore con comportamento aggiuntivo che cambia il contrasto della foto (nell'applicazione) e ridisegna quest'ultima (nell'interfaccia)

Funzioni callback

Per associare comportamenti aggiuntivi ai dispositivi di interfaccia, le librerie / toolkit prevedono il meccanismo delle callback.

Callback = funzione "da chiamare in risposta" a un evento che accade su un certo componente di interfaccia.

Una callback e' una funzione scritta dal programmatore, il quale poi comunica alla libreria che dovra' chiamare questa funzione ogni volta che un certo tipo di evento si verifichera' su un certo componente di interfaccia. La funzione verra' poi chiamata automaticamente.

Al suo interno una funzione callback puo' accedere sia all'interfaccia (tramite le funzioni della API del toolkit), sia all'applicazione sottostante. Esempio: eseguire un calcolo applicativo e poi mostrare il risultato nell'interfaccia.

Programmatore scrive una funzione con parametri conformi a quelli stabiliti dal toolkit e poi la registra come callback.
Al verificarsi dell'evento, il toolkit chiamera' la callback (a seguito del verificarsi dell'evento), e le passera' automaticamente i parametri prelevandoli dall'evento attuale.

Struttura del codice di un programma che implementa un'interfaccia utente (per una certa applicazione) facendo uso di un toolkit.

Vediamo le parti del programma (a livello di codice scritto dal programmatore) e che cosa succede dentro (a livello della libreria / toolkit).

Che cosa scrive il programmatore		Che cosa avviene nella libreria / toolkit
1. Dichiara che intende usare il toolkit	Direttiva include in C, import in java...
2. Inizializza il toolkit	Istruzione della API del toolkit. Certi toolkit (es. java) non richiedono inizializzazione esplicita.	Libreria si collega a librerie di piu' basso livello che le permetteranno di produrre grafica e catturare eventi (ved. punto 3)
3. Crea l'interfaccia (creare le finestre, i dispositivi, personalizzarne l'aspetto, posizionarli...)	Istruzioni della API del toolkit	Libreria costruisce la grafica e i comportamenti predefiniti usando librerie di piu' basso livello fornite dal sistema operativo o comunque da strati software inferiori.
4. [a parte] Scrive le callback per implementare i comportamenti aggiuntivi (es. accedere all'applicazione sottostante)	Programmatore scrive una funzione con parametri e valore di ritorno conformi a quelli stabiliti dal toolkit per callback a quel tipo di evento in quel tipo di componente.
5. Registra le callback, cioe' associare le funzioni-comportamenti ai dispositivi	Istruzioni della API del toolkit per registrare la funzione come callback a quel componente per quel tipo di evento.	Libreria compila una tabella di associazioni dispositivo - tipo di evento - funzione callback.
6. Mostra a schermo l'interfaccia (almeno la finestra principale, mentre altre possono essere pensate per apparire a seguito di eventi)	Istruzioni della API del toolkit per rendere visibili le finestre	Libreria mappa finestre sullo schermo
7. Fa partire il ciclo degli eventi, cioe' l'interazione con l'utente (azione - evento - reazione - feedback...)	Istruzione della API del toolkit. Certi toolkit (es. java) non hanno un'istruzione esplicita, il ciclo degli eventi parte automaticamente non appena viene mostrata una finestra.	Libreria esegue ciclo infinito in cui ad ogni giro: attende un evento guarda il tipo di evento e il componente su cui si e' verificato esegue la reazione predefinita per quel tipo di evento su quel tipo di componente guarda (nella tabella) se per quel tipo di evento e quel componente e' stata registrata un callback, se si' la esegue

Tutti i passi tranne 4 compaiono in questa sequenza nel codice del main. Le callback (passo 4) sono ovviamente funzioni scritte a parte.
Dopo eseguita l'ultima istruzione del main il programma non termina perche' intanto e' stato avviato il ciclo degli eventi.
Il ciclo degli eventi (passo 7) va avanti potenzialmente all'infinito, a meno che in qualche callback si incontri l'istruzione di terminazione.

Interazione bloccante e non bloccante

Riguarda la gestione del ciclo degli eventi.

• Interazione bloccante
  Flusso del programma completamente guidato da eventi.
  Finche' non arriva un evento, il programma dorme (interazione bloccata) e non usa CPU.
  Quando riceve un evento, allora si risveglia (riprende l'esecuzione) per reagire all'evento.
  Corrisponde allo schema appena visto.

• Interazione non bloccante
  Programma oltre a reagire agli eventi esegue anche operazioni autonome, indipendenti dagli eventi (es: animazione).
  Mentre attende che arrivino eventi, nel frattempo esegue le sue operazioni (consumando CPU). Se arriva un evento, allora interrompe la sua normale attivita' per reagire all'evento.

Come si realizza l'interazione non bloccante?

• Alcuni toolkit prevedono uno speciale evento nullo corrispondente ad assenza di eventi. A questo posso associare una callback, chiamata idle callback, che implementi l'operazione autonoma.

• Altri toolkit (es. java) prevedono timer con cui posso scatenare un evento ogni tot di tempo. A questo evento "fittizio" posso associare una callback che implementi l'operazione autonoma.

Tipi di dispositivi

I dispositivi forniti da una libreria / toolkit sono elementi di interfaccia pronti all'uso (bottoni, menu'...).

Si classificano in diversi tipi o classi, ciascun tipo con certe caratteristiche di aspetto / comportamento.

• Elementi attivi (sensibili a input):

  • menu' (permettono di immettere una scelta da una lista di opzioni)
  • bottoni (sensibili al click)
  • dispositivi per introduzione di testo (campi di input)
  • dispositivi per introduzione di valori numerici (contatori, potenziometri)

• Elementi inerti (solo aspetto grafico):

  • etichette testuali
  • etichette grafiche (bitmap, pixmap)
  • cornici ed altri elementi decorativi

• Aree dedicate a scopi speciali: aree grafiche, aree per visualizzazione o editing di testi...

Come possiamo vedere un dispositivo

Dal punto di vista dell'utente dell'interfaccia un dispositivo / componente di interfaccia e' caratterizzato da:

• una grafica che costituisce la sua apparenza
• comportamento predefinito rispetto a certi eventi che sono gestiti internamente a cura del toolkit
• comportamento personalizzabile rispetto a certi eventi che sono gestiti a cura dell'applicazione (tramite la mediazione della sua interfaccia)

Dal punto di vista del programmatore un componente e' caratterizzato da:

• uno stato, descritto da un insieme di variabili interne proprie del componente
• un insieme di funzioni API per interrogare e manipolare lo stato
• un insieme di eventi che possono essere intercettati dal componente
• un meccanismo per "aggangiare" a tali eventi procedure callback

Gestione degli eventi nei componenti

Quando su un componente di interfaccia avviene un evento, il toolkit lo puo' gestire come:

• Evento interno: usato solo internamente al toolkit per cambiare lo stato del componente, senza interessare l'applicazione.
• Evento esterno: potenzialmente interessante per l'applicazione, per poterlo intercettare l'applicazione (o meglio alla parte di codice che implementa l'interfaccia dell'applicazione) deve aver registrato una callback

Esempi

Bottone che si evidenzia quando l'utente ci passa sopra col mouse e scatta quando preme:

• evento entrata / uscita del mouse dall'area del bottone e' gestito dal toolkit mediante cambiamento di colore del bottone
• evento pressione del mouse e' gestito da applicazione stabilendo callback da invocare

Campo testuale (per l'immissione di una stringa di testo):

• evento "pressione del mouse" e' usato internamente al toolkit per attivare il campo di testo
• a campo di testo attivo eventi "pressione di caratteri" sono usati internamente per aggiornare il contenuto del campo
• evento "pressione del tasto return" e' passato all'applicazione, che deve avere stabilito una callback per gestirlo (es. per leggere la stringa immessa e farne qualcosa...)

Slider o potenziometro (barra di scorrimento per l'immissione di un valore numerico in un certo intervallo):

• gli eventi generati dall'utente trascinando il cursore mobile sulla barra sono gestiti internamente ed usati per aggiornare la posizione del cursore
• lo stato interno dello slider comprende il valore della posizione corrente e puo' essere interrogato dall'applicazione
• l'applicazione puo' agganciare una callback che scatti ogni volta che l'utente ha terminato di manipolare lo slider (es. leggere il valore e farne qualcosa)

Componenti di base e contenitori

Due categorie fondamentali di componenti:

• componenti di base: servono per presentare informazioni all'utente e/o ricevere input da questo, sono i dispositivi sopra citati.
• componenti contenitori: servono per raggruppare altri componenti in un contesto grafico.

Mediante i contenitori si struttura lo spazio della finestra definendo vincoli per la disposizione (layout) dei componenti al suo interno. Meccanismo a scatole cinesi (gerarchia di annidamento dei contenitori).

Esempio: la finestra e' divisa in due parti verticalmente, nella parte sinistra c'e' un'area di testo, la parte destra e' strutturata come una griglia 3 righe x 3 colonne con dentro dei bottoni.

+--------------------+----+----+----+
|                    | B1 | B2 | B3 |
|                    +----+----+----+
|    area di testo   | B4 | B5 | B6 |
|                    +----+----+----+
|                    | B7 | B8 | B9 |
+--------------------+----+----+----+

       contenitore a due scomparti verticali
                        |
             +----------+----------+
             |                     |
    area di testo        contenitore a griglia 3x3
                                     |
                               +-----+-----+
                               |    ...    |
                        bottone B1  ...  bottone B9

Con contenitori posso raggruppare componenti concettualmente collegati, disegnare bordi e cornici.

GUI Designer

Un toolkit puo' fornire un GUI Designer (chiamato altrimenti GUI Builder). Programma interattivo che permette la progettazione e la realizzazione di interfacce grafiche basate su tale toolkit.
Quello che si realizza e' lo scheletro dell'interfaccia utente, senza i comportamenti aggiuntivi (per quelli devo poi scrivere io le callback).

• si possono creare finestre, bottoni, slider, menu' istanziando degli schemi predefiniti (per ogni classe di componente fornita dal toolkit)
• si possono dimensionare, posizionare tali oggetti nell'interfaccia usando manipolazione diretta
• si puo' associare direttamente alla pressione di un tasto in un menu' l'attivazione di sottomenu', apertura di finestre di dialogo...

Il GUI Designer produce il codice relativo all'interfaccia.

Il programmatore deve solo riempire il corpo delle procedure callback associate ai componenti.

Esempi di GUI Designer disponibili

Nota bene: per IDE (Integrated Development Environment) si intende un ambiente integrato per lo sviluppo di applicazioni, pacchetto che comprende editor, compilatore, interprete, facilita' per debugging ecc.

• Netbeans ( http://netbeans.org/community/releases/68/):
  Ambiente di sviluppo Java (Java IDE), comprende uno Swing GUI builder (per realizzare interfacce grafiche con il toolkit Java Swing), ma e' molto di piu'.
  Oltre che Java supporta altri linguaggi: C++ ecc. e disponibile su varie piattaforme (Windows, Linux, Mac). Ha anche librerie aggiuntive rispetto a quelle di Java.

• Eclipse ( http://www.eclipse.org/home/newcomers.php):
  E' un Java IDE, ma non solo. E' pensato per permettere lo sviluppo di progetti dall'inizio alla fine del loro ciclo di vita (progettazione, implementazione, verifica, ecc.).