CAPITOLO 4
4.1. Le classi *
4.2. Le immagini *
4.3.1. L’ACQUISIZIONE DELLE IMMAGINI *
4.3.2. FORMATI E DIMENSIONI DELLE IMMAGINI. *
4.3. I suoni *
Il programma "La mia casa" si basa sulle classi fornite con il JDK 1.0.2. A queste classi ne sono state aggiunte altre, alcune nuove mentre molte altre derivate da quelle fornite dal JDK.
Partendo dalla classe firstPageApplet che è quella che viene inserita nella pagina HTML, le classi principali che compongono il programma sono centralPanel, mainWindow, objectLoader e dataStrip. Si può rappresentare uno schema di massima dell'interazione che esiste tra queste classi con la figura 4.1, dove viene descritto come sono istanziate e inizializzate.
La classe centralPanel è derivate dalla classe Panel fornita con il package java.awt ed è quella che gestisce l'interfaccia e l'interazione con l'utente durante le lezioni del corso, infatti ogni oggetto di tipo centralPanel gestisce per ogni lezione le animazioni, la trattazioni degli eventi legati al mouse, alla tastiera e la gestione dei suoni legati alla pronuncia degli oggetti. Per ogni lezione ("teoria", "gioco dei 5 cubi", "Pillo si mangia tutto", "Pillo dipinge il mondo", o "costruisci il tuo ritratto"), viene creata una classe specifica che è derivata dalla classe centralPanel o da una sua sottoclasse. Queste sottoclassi sono descritte nella loro gerarchia nella figura 4.2 e sono le classi centralPanelTheory, centralPanelGame, centralPanelGameClassic, centralPanelGameLand, centralPanelColor1.
Gli scenari delle stanze vengono ricomposti dentro queste classi a partire dalle immagini singole degli oggetti che arredano la stanza e dall'immagine dello sfondo spoglio. Grazie agli oggetti di tipo dataStrip, come spiegato più avanti, sono note tutte le informazioni necessarie per disporre tutte le immagini nella giusta posizione.
Dentro le classi centralPanelTheory, centralPanelGameClassic e centralPanelGameColor1, sono ridefiniti i metodi per sentire i clic e gli spostamenti del mouse per sapere così quali oggetti l'utente ha selezionato, o dove vengono portati e lasciati. Nella classe centralPanelGameLand invece gli eventi che vengono gestiti sono quelli relativi alla pressione dei tasti della tastiera, dato che in questo tipo di gioco non sono previste interazioni con il mouse.
All'interno della classe centralPanelGame ( sono definiti quei metodi che servono per scegliere in maniera casuale quali oggetti usare per gli esercizi, questi metodi sono poi ereditati da tutte le sottoclassi di centralPanelGame.
In tutte le sottoclassi di centralPanelGame, come anche nella classe centralPanelIdentikit, viene creato e gestito un thread per le animazioni di Pillo e per l'esecuzione del gioco.
Le altre classi che compongono l'interfaccia principale del programma sono sempre sottoclassi di Panel e sono in particolare la classe eastPanel che gestisce la toolbar posta a destra dello schermo, la classe hintsPanel posta in fondo allo schermo che gestisce i commenti, i suggerimenti e le risposte relative alla schermata del momento. Anche gli oggetti di tipo hintsPanel e eastPanel, come tutti gli oggetti di tipo centralPanel sono istanziati e gestiti, per quanto riguarda la loro posizione sullo schermo, dalla classe mainWindow.
Come si evince dalle funzioni svolte dalla classe centralPanel e dalle sue sottoclassi, l'interfaccia è legata alla logica del programma, un fattore dovuto anche al modo in cui Java nella versione 1.0.2 gestisce gli eventi, infatti ogni componente dell'interfaccia in Java ha la possibilità di sentire e gestire gli eventi al proprio interno ridefinendo i metodi appropriati.
La classe mainWindow è derivata dalla classe Frame del package java.awt, e scopo principale di questa classe è di fornire la finestra (un Frame è appunto una top level window) dove si svolge il corso e che appare dopo aver premuto il bottone sulla pagina HTML, l'oggetto di tipo mainWindow viene infatti creato dall'applet.
I metodi di mainWindow gestiscono il susseguirsi delle schermate o per essere più precisi il susseguirsi sullo schermo delle istanze della classe centralPanel in base agli eventi registrati dalla toolbar o dai centralPanel stessi. Il passaggio tra un oggetto ti tipo centralPanel ed un altro avviene usando un altro layout manager, il cardLayout, fornito nel package java.awt; con questo layout manager gli oggetti di tipo centralPanel sono come un mazzo di carte dove quella visibile è quella in cima al mazzo. Dentro mainWindow inoltre ci sono i metodi per avviare e controllare i thread che caricano dalla rete le immagini e i suoni relativi ad ogni lezione per inizializzare così gli oggetti di tipo centralPanel.
La classe dataStrip è stata creata per riunire tutte le informazioni riguardanti gli oggetti che arredano le stanze, per ogni oggetto infatti bisogna conoscere l'immagine che lo raffigura, il suono della pronuncia, le coordinate dove tale oggetto deve essere disegnato nella stanza, la regione che occupa sullo schermo, la parola inglese che identifica tale oggetto, nonché molte altre informazioni per riprodurre la profondità della stanza, come per esempio se tale oggetto, parzialmente o totalmente, copre o è coperto da altri oggetti e l'indicazione di quali immagini usare per riprodurre la corretta prospettiva della stanza. Per ogni arredamento usato nel corso viene quindi istanziato un oggetto di tipo dataStrip che lo identifica, infatti gli oggetti di tipo centralPanel per gestire e posizionare le immagini degli oggetti che arredano una stanza e per rispondere alle interazioni dell'utente durante una qualsiasi lezione del corso, usano un vettore di oggetti di tipo dataStrip.
La classe objectLoader ha il delicato compito di inizializzare gli oggetti di tipo dataStrip, centralPanel, eastPanel e hintsPanel. Un oggetto di tipo objectLoader, instanziato da un oggetto di tipo mainWindow, prende tutti i dati riguardante l'inizializzazione di ogni oggetto di tipo dataStrip da un file, che per esigenze di sicurezza è un file HTML, e da questo file ricava per ogni oggetto il nome del file che contiene l'immagine, il nome del file audio, le coordinate e la regione che l'immagine occupa e tutte le altre informazioni necessarie. Per evitare che durante il periodo di caricamento dei dati l'applet non ascolti più le interazioni dell'utente, tale attività viene affidata ad un thread creato e gestito dalla classe objectLoader.
Una tipica interazione tra queste classi sopra descritte avviene quando si deve passare da una lezione ad un'altra. La classe mainWindow quando si accorge (tramite un bottone della toolbar, o messaggio del centralPanel attivo in quel momento o tramite un messaggio dell'indice) che il centralPanel mostrato sullo schermo deve essere cambiato, gli manda un messaggio di terminare per far liberare le risorse usate e soprattutto per far terminare eventuali thread attivi. L'oggetto di tipo mainWindow quindi richiede all'oggetto di tipo objectLoader il caricamento, attraverso la rete, dei dati relativi al prossimo centralPanel da mostrare e di tutti i dataStrip necessari; tramite le chiamate ad alcuni metodi di objectLoader attiva il thread di caricamento dei dati e si sincronizza in attesa che il processo di caricamento sia terminato. Al termine del caricamento di tutti i dati mainWindow, con i metodi forniti dal cardLayout, mostra il nuovo centralPanel sullo schermo che può così iniziare la sua attività.
Oltre alle classi caricate con l'applet attraverso la rete per l'esecuzione del programma, esistono altre due classi residenti sulla macchina server che devono rimanere sempre in esecuzione. Uno di questi programmi è dato dalla classe socketServer, questa classe deve rimanere perennemente in ascolto sulla porta 4444 in attesa di messaggi da parte dell'applet. L'applet infatti in certi momenti della sua vita può aver bisogno di alcune informazioni registrate sull'host dove è in esecuzione socketServer, in particolare l'applet può aver bisogno di leggere la classifica attuale dei bambini che hanno partecipato al corso o la deve aggiornare o infine può spedire a socketServer la richiesta di traduzione di una parola inglese. Tutte queste funzioni sono lasciate alla responsabilità di socketServer, sia per praticità, soprattutto per quanto riguarda il dizionario, sia per le limitazioni delle applet che non possono leggere e scrivere su file del sistema sul quale sono in esecuzione. In tutti questi casi l'applet invia attraverso la socket aperta verso socketServer le richieste e rimane in attesa della conferma della riuscita dell'operazione o dell'invio della risposta. La classe socketServer è progettata per essere multiuser, cioè più utenti possono accedere contemporaneamente alla piena funzionalità dell'applet.
L'altro programma che deve essere sempre in esecuzione è dato dalla classe HTTPServer che implementa al suo interno un server HTTP che permette il caricamento da parte di qualsiasi browser dell'applet "La mia casa!. Tale programma si rende necessario solo se l'host dove è in esecuzione socketServer è diverso dall'host dal quale viene prelevata l'applet. Infatti per motivi legati alla sicurezza, i browser impediscono ad una applet di aprire liberamente connessioni attraverso la rete, le uniche connessioni che possono essere aperte sono solo quelle verso l'host dal quale l'applet proviene.
La necessità di creare un server HTTP è dovuta al fatto che l’applet si trova sulle nostre homepage che vengono distribuite attraverso l’host www.cli.di.unipi.it, mentre il server della nostra applicazione è in esecuzione sulle macchine disponibili per gli utenti del centro di calcolo in particolare su lina.cli.di.unipi.it. Quando l’applet tenta di aprire una connessione verso l’host su cui è in esecuzione il socketServer si verifica un’eccezione, perché non è lo stesso host da cui è stata prelevata. La soluzione che abbiamo pensato è stata l’utilizzo di un server HTTP in esecuzione su lina che provveda a distribuire la nostra homepage, in tal modo le connessioni che l’applet avvia sono rivolte allo stesso host da cui è stata prelevata e tutto funziona.
Per avere i disegni necessari a realizzare il corso di inglese erano percorribili due strade principali, la prima alternativa era quella di cercare illustrazioni in genere, quindi sia disegni che fotografie, già "pronti" sia presi da fonti cartacee come riviste, libri, giornali, che da prodotti informatici esistenti quali CD ROM di immagini. La seconda via era invece quella di realizzare i disegni necessari direttamente su computer o prima su carta per poi digitalizzarli su computer.
La prima soluzione di ricercare immagini esistenti crea delle difficoltà sia per quanto riguarda la successiva strutturazione del corso, che è in questo modo vincolato alle immagini effettivamente trovate, che per la ricerca stessa delle immagini. Infatti si deve anche effettuare una scelta del tipo di immagini da usare se fotografie o disegni, una scelta è obbligatoria in quanto per avere un migliore impatto verso l’utente il prodotto deve cercare di mantenere una coerenza grafica tra le varie videate del corso e quindi non è proponibile l’uso promiscuo di disegni e fotografie sia alternati tra videate diverse che in coabitazione nella stessa schermata.
Nel caso la scelta cada sull’uso delle fotografie la ricerca di materiale adatto è agevolata dal fatto di poter integrare facilmente immagini mancanti con fotografie proprie scattate ad hoc, ma un’interfaccia realizzata con fotografie risulta per una utenza composta da bambini meno accattivante di una realizzata interamente da disegni. Se quindi si vuole andare incontro il più possibile ai gusti dei bambini che useranno il corso è indispensabile l’uso abbondante di disegni che abbiano uno stile vicino al fumetto o al cartone animato, in questo caso la ricerca di materiale esistente è molto più complessa perché anche se esiste una grossa produzione di fumetti, il vincolo di mantenere uno stile unico del disegno impone di cercare un autore e inoltre introduce anche problemi legati al diritto di autore.
L’altra strada percorribile, che è stata poi adottata per questo prodotto, è quella di disegnare tutti gli ambienti, gli oggetti e le strip relative alle animazioni necessari per il corso, vengono realizzate le tavole e mediante uno scanner si digitalizzano i disegni che sono così pronti per essere gestiti dal programma. Questa soluzione è ottima per quanto riguarda la progettazione del corso, infatti non esiste più nessun vincolo di adattarsi alle immagini trovate, ma si è liberi di inventare gli ambienti preferiti. Anche se sembra la soluzione più naturale, cioè disegnare le immagini che servono, è anche una strada impossibile per chi non ha talento nel disegno, la realizzazione di questo tipo di tavole richiede infatti fantasia, tecnica ed anche uno stile mirato ad incontrare il gusto del bambino. Ovviamente la difficoltà più grande è stata quella di trovare una persona che avesse tutte queste caratteristiche e che volesse prestarsi a partecipare a questo progetto di un corso di inglese per bambini. Questo impegno ha accettato di assumerselo Jacopo Allodi, un artigiano di Firenze che crea oggetti in legno dai giocattoli ai soprammobili ed inoltre è appunto un bravo disegnatore con alle spalle anche un corso per fumettista frequentato a Milano. Grazie anche al rapporto di amicizia che già esisteva la collaborazione è sempre stata fluida, Jacopo è anzi sempre riuscito ad inserire in tutte le tavole che gli abbiamo richiesto la sua fantasia, con il suo tratto semplice, con cui riesce a giocare con le prospettive e le forme delle cose. Il compito che gli abbiamo chiesto non è stato facile, da un lato c’è stato un lavoro di quantità dato dal numero di tavole che ha dovuto comporre, e dall’altro lato gli abbiamo chiesto anche un lavoro di qualità che rispettasse uno stile di disegno adatto ai bambini, dimensioni dei disegni che dovevano rispettare dei rapporti precisi tra altezza e larghezza della tavola e inoltre disegnare le stanze e gli oggetti da noi chiesti in maniera tale che tutti fossero ben visibili a scapito anche di alcune regole di prospettiva.
La produzione di Jacopo Allodi è stata di sei tavole riguardanti le stanze della casa dove ambientato il corso, una ulteriore tavola per la sezione della casa che funziona da indice, tre tavole di oggetti da aggiungere a quelli già disegnati nelle tavole delle stanze, più di venti tavole per le animazioni della mascotte Pillo, nove tavole per l'animazione di Pillo che dipinge, una quindicina di tavole per la composizione dei ritratti dei bambini, e di numerose altre immagini per i bottoni del corso; in totale all’interno di tutte le tavole sono stati disegnati più di cento oggetti.
Se per le tavole riguardanti le stanze e gli oggetti al loro interno i vincoli richiesti erano la visibilità e il rapporto tra base ed altezza della dimensione della stanza, così da mantenere una uniformità tra le tavole, per quanto riguarda i disegni relativi alle animazioni i problemi erano molto diversi, infatti per disegnare una strip (una sequenza di disegni) che realizzi una animazione, i disegni che rappresentano i fotogrammi devono avere assolutamente dimensioni identiche e le parti di disegno che da un fotogramma all’altro non cambiano (per esempio i piedi di Pillo durante l’animazione di Pillo che mangia tutto) devono combaciare nella posizione relativa all’interno di tali fotogrammi, figura 4.3.
Lo stile del disegno è un tratto detto a "linea chiara", nel senso che con questo tipo di tratto non ci sono chiari scuri, non ci sono sfumature, retini o toni di grigio, le linee sono nette e i contorni dei disegni sono tutti ben definiti. Altri tipo di tecniche che potevano essere usate erano quelle a pennello secco o altre ancora, ma il tratto a linea chiara era quello che garantiva un impatto più immediato per la comprensione del bambino.
Tutti i disegni sono stati realizzati in bianco e nero ed inchiostrati solo con la china, la colorazione è stata poi fatta con il computer, questa scelta di lasciare le tavole in bianco e nero è stata dettata da due fattori: il primo è dovuto al tempo di realizzazione che sarebbe aumentato considerevolmente se Jacopo Allodi avesse dovuto anche colorare i disegni , il secondo è dato dalla possibilità di fare più facilmente con il computer prove di colore sostituendo di volta in volta un colore con un altro.
L’eventuale colorazione fatta direttamente da Jacopo Allodi infatti prevede una procedura abbastanza complessa e anche economicamente dispendiosa. Nel tratto a linea chiara e colore, corrispondente a produzioni del tipo "Topolino" o "Il Giornalino" la colorazione delle tavole prevede come primo passo di stampare il disegno su una lastra di acetato (fogli di plastica trasparente); quindi si attacca la lastra di acetato sul retro di un foglio o cartoncino e lo si pone sulla superficie di una lavagna luminosa. Con il tavolo retro illuminato si può così dipingere sul cartoncino che fa trasparire il contorno del disegno stampato sull’acetato.
Con questo sistema di colorazione si ottengono almeno due vantaggi, il primo è dato dal fatto che il disegno originale (sull’acetato) non rischia di essere rovinato da eventuali errori di colorazione, il secondo è invece dato dal fatto che eventuali piccole sbavature verranno poi coperte dalla linea del contorno del disegno in fase di stampa vera e propria. Finita la colorazione, per avere l’immagine al computer si sarebbe dovuto inserire in uno scanner il cartoncino così colorato con, stavolta attaccato di fronte, la lastra di acetato; lo scanner avrebbe così acquisito i contorni dell’immagine disegnata sull’acetato sopra i colori dipinti sul cartoncino.
Cambiando tipo di tratto, quindi non più a linea chiara, Jacopo Allodi avrebbe potuto fare direttamente sulle tavole delle pitture, cioè disegnare stanze ed oggetti direttamente con i colori senza il contorno nero, questa tecnica è però più lunga e complicata, inoltre il disegno ha un impatto diverso e meno familiare ai bambini.
4.2.1. L’ACQUISIZIONE DELLE IMMAGINI
L’acquisizione delle immagini si è rivelato un momento delicato del progetto, infatti anche in questa fase abbiamo dovuto fare delle scelte di progettazione e assimilare le metodologie e tecniche di acquisizione delle immagini tramite scanner e di elaborazione, gestione e colorazione delle immagini così ottenute. Le difficoltà incontrate sono state diverse a seconda se le tavole erano inerenti le stanze e l’arredamento relativo o se erano tavole riguardanti le strip che componevano una animazione.
Come già detto alcune di queste tavole erano composte dai disegni di una stanza (per esempio il bagno) comprensivo di un arredamento quasi completo (per esempio il lavandino, lo specchio, il pettine, ecc.). Quando l’immagine veniva acquisita con lo scanner il risultato era quello di avere una singola immagine comprensiva di tutti o quasi, gli oggetti della stanza, in realtà dato che le funzionalità del programma prevedono che gli oggetti possono essere spostati o selezionati singolarmente o possono addirittura sparire, era necessario avere per ogni oggetto una immagine singola indipendente dallo sfondo della stanza.
Disegnare una unica tavola con la stanza della casa parzialmente arredata è più comodo per il disegnatore che può organizzare in modo migliore e più organico gli spazi all’interno della stanza, curare più facilmente gli aspetti legati alla prospettiva e alle proporzioni tra gli oggetti. Per questa ragione è stato deciso di acquisire l'immagine della stanza completa di arredamento e oggetti per poi ricavare le immagini dei mobili e degli oggetti con un programma di grafica.
Con Paint Shop Pro venivano ritagliate dalle immagini acquisite con lo scanner, le immagini dei mobili e degli altri oggetti che venivano poi registrate come immagini nuove; questa procedura è stata resa possibile con opportune funzioni di Paint Shop Pro che permettono di selezionare con il mouse regioni rettangolari dello schermo (che iscrivono l’oggetto da ritagliare), e di ricopiarle su di una nuova immagine indipendente da quella originaria. Iterando il procedimento per tutti gli n oggetti che compongono l’arredamento della stanza, lo stato che si raggiunge è quello di avere l’immagine originale da una parte e dall’altra n nuove immagini relative agli n oggetti che volevamo ricavare.
A questo punto i disegni non sono ancora pronti per essere colorati, perché sia per la vicinanza con un altro oggetto, sia per motivi legati alla prospettiva, porzioni di altri disegni possono essere stati copiati, le immagini devono quindi essere "ripulite" e se necessario ritoccate nei contorni, se per esempio l'oggetto era coperto da altri disegni, figura 4.4.
Anche per il disegno originale deve essere effettuata un’opera di pulizia, infatti devono essere cancellati tutti i mobili che sono diventati disegni a se stanti, ma soprattutto devono essere disegnati i contorni della stanza che tali arredamenti coprivano.
Quando queste operazioni si sono concluse i disegni ottenuti, ancora in bianco e nero, sono il contorno degli oggetti, per quanto riguarda le immagini ritagliate, e la stanza spoglia per quanto riguarda quella che era l’immagine originale, solo a questo punto si può colorare le immagini così ottenute.
Per far ricomporre al programma l’immagine intera si deve necessariamente tenere traccia della posizione dei vari oggetti nel disegno della stanza, così ogni volta che viene copiata un’area dello schermo (un rettangolo come già detto in precedenza) vengono segnate le coordinate (in pixel) del vertice in alto a sinistra dell’area e la lunghezza e la larghezza (sempre in pixel) di tale area. Queste informazioni vengono poi memorizzate in una particolare struttura dati del programma, necessaria appunto alla ricostruzione della stanza al momento della sua visualizzazione.
4.2.2. FORMATI E DIMENSIONI DELLE IMMAGINI.
La ricostruzione del disegno di una stanza è data così dalla sovrapposizione dei disegni dell’arredamento a quello della stanza spoglia ricavato come descritto precedentemente e che ha ora la funzione di sfondo per tutte le altre immagini. A questo scopo il formato delle immagini degli oggetti dell’arredamento deve assolutamente essere in formato GIF, perché questo formato, oltre che essere uno dei due supportato da Java che ne riconosce automaticamente la codifica, è anche un formato di immagini che permette di avere lo sfondo trasparente. Senza la trasparenza dello sfondo un’immagine, che è sempre un rettangolo di pixel, potrebbe coprire con il proprio sfondo un altro oggetto e sicuramente parte dei muri della stanza stessa.
Durante la manipolazione delle immagine è importante il formato che viene usato, cioè con che codifica vengono registrate su disco le modifiche che vengono fatte, perché alcuni formati (per esempio il formato JPG) sono a perdita di informazione, nel senso che ogni volta che viene registrata una modifica, durante la compressione e codifica del file alcune informazioni (contorni, tonalità di colore) vengono persi o cambiati, si tratta di perdite minime ma non trascurabili, infatti durante successive modifiche dello stesso disegno le differenze soprattutto nei colori di porzioni di sfondo in tinta unita erano abbastanza visibili. Altri formati invece (per esempio i formati BMP, TIFF o GIF) durante la registrazione delle immagini non perdono informazioni, infatti poiché non comprimono dati non c’è nessuna modifica dei valori di colore dei pixel a scapito di una maggiore dimensione di byte occupati su disco. Queste considerazioni sono ovviamente valide anche in fase di prima registrazione dopo l’acquisizione tramite scanner, infatti una volta acquisita l’immagine andava registrata su floppy disk per essere poi elaborato su altri computer.
Un'altra elaborazione preliminare da fare sulle immagini appena acquisite ha riguardato la loro dimensione, infatti appena scansionate le dimensioni in pixel erano molto superiori a quelle stabilite per lo schermo alla risoluzione 800x600 pixel, quindi una operazione delicata dal punto di vista della perdita di informazione o di definizione del tratto, era ridimensionare le immagini a dimensioni di 740x493 pixel. Questa operazione è sempre stata effettuata tramite il comando resample di Paint Shop Pro e la definizione dell’immagine non è stata compromessa anche grazie al rapporto tra le dimensioni dell’altezza con la larghezza delle tavole che Jacopo Allodi a mantenuto costanti durante tutti i disegni come stabilito a priori, infatti in questa maniera è stato possibile per chi disegna mantenere le dimensioni preferite e per chi elabora i disegni di ridimensionarli tutti alle stesse misure.
Tutti i suoni usati durante il corso sono registrati nel formato .au, l'unico supportato da Java, che è uno degli standard usato su Internet.
I suoni che accompagnano le risposte dell'utente durante i giochi sono effetti speciali trovati attraverso Internet.
Le pronunce di tutti i vocaboli sono invece frutto del campionamento su personal computer delle nostre voci grazie ad un microfono, ad una scheda audio inserita nel computer e all’elaborazione e conversione dei suoni così ottenuti con il programma Goldwave.
La sigla, nonché colonna sonora del corso, è un motivetto composto apposta per il corso da Marco Gagliardi diplomatosi al conservatorio di musica a Firenze. Il motivo è stato composto con una tastiera elettronica ed è formato da un ritornello che si ripete per due volte seguito dal finale che è una citazione dell'inno nazionale inglese. Durante il programma questo motivo viene fatto proseguire in un loop fino a che non inizia una delle lezioni del corso.