1. Xt/Motif, librerie dell’ambiente grafico di UNIX X-Windows, sistema operativo che ultimamente forse ha perso un po’ di smalto, ma che si trova ancora sulla cresta dell’onda per la sua provata versatilità e affidabilità;
2. MFC, o Microsoft Foundation Classes, sviluppate dalla Microsoft e concepite solo per applicazioni in ambiente Windows, che sostanzialmente ha preso il primato in quanto a base installata;
3. JFC (Java Foundation Classes) e Swing, la libreria di Java per applicazioni grafiche sviluppata dalla SUN in collaborazione con Netscape e altre aziende. Swing rappresenta, per la sua completezza e l’adozione di avanzati concetti di Object Oriented Design, un notevole passo in avanti nel panorama delle librerie grafiche.

Verranno qui analizzate le principali differenze di questi tre ambienti grafici, sempre dal punto di vista di Java. Per una descrizione in dettaglio delle librerie Swing, si rimanda il lettore alla sezione dei riferimenti, ed in particolare agli articoli comparsi nei mesi scorsi su Mokabyte. Nella trattazione delle caratteristiche principali si lascia inoltre Swing volutamente per ultima, poiché essa trae vantaggio da alcune caratteristiche che le altre due intrinsecamente possiedono.
 

Motif

Figura 1 - Architettura del sistema grafico di UNIX X-Windows, Xt e Motif

La parte più a basso livello è costituita dalle librerie grafiche Xlib, che forniscono le primitive necessarie per manipolare entità e concetti grafici elementari (aree grafiche, coordinate, punti, linee, finestre), dispositivi di I/O (mouse, tastiera) e tutti gli eventi ad essi collegati. Teoricamente, già con Xlib si potrebbe fare qualunque cosa, a prezzo però di un codice troppo lungo e complicato: anche il ciclo principale di gestione degli eventi, quasi sempre mascherato al programmatore, qui sarebbe a suo carico. Con un paragone, si può dire che le Xlib siano allo stesso piano di ciò che l’assembly rappresenta nel panorama dei linguaggi di programmazione.
Ad un livello intermedio si colloca la libreria Xt Intrinsics. Essa è stata concepita per dare ai programmatori tutti i tipi di entità grafiche che siamo abituati a vedere in un sistema a finestre. Il componente generico (finestra, bottone, menù, etc.) è chiamato Widget, e la sua gestione tramite le primitive fornite dalle Xlib è completamente mascherato allo sviluppatore, alla pari di alcune funzioni di base, come il già citato ciclo degli eventi di un’applicazione.
Ad un livello più elevato si collocano librerie che basandosi su Xt definiscono insiemi di componenti con funzionalità abbastanza specializzate. Abbiamo quindi diverse librerie in commercio, come Openlook, Athena e Motif, che in realtà è quella di gran lunga più apprezzata e diffusa. Come appare anche dalla Figura 1, la compenetrazione di Xt e Motif è molto spinta, tanto che le primitive da esse fornite sono chiamate nell’ambito della stessa applicazione semplicemente a seconda del bisogno e di quali componenti si intenda usare per fornire le funzionalità richieste. Anche se dalla figura è visibile (e lecito) il ricorso diretto a primitive di Xlib, questo sarà limitato solamente a casi  particolari. 
Le librerie Xt e Motif possiedono una struttura che concettualmente collima con una filosofia orientata agli oggetti: tuttavia, esse sono scritte in C semplice, e sono a loro volta concepite per essere usate in programmi C, che è il linguaggio base di UNIX. Quindi, in linea teorica, usando queste librerie non si possono scrivere programmi in linguaggi OO; per Motif esistono delle implementazioni in C++ (es. Motif++), le quali però di fatto si limitano a costituire una mascheratura (wrapper) delle versioni scritte in C. Queste caratteristiche di design possono talvolta costituire un ostacolo alla realizzazione di applicazioni completamente OO.
Il supporto al Look and Feel (cioè, l’aspetto estetico) è, con X-Windows e quindi Xt e Motif, estremamente completo, sia nei confronti di una singola applicazione, sia per gruppi di applicazioni definibili dal programmatore. Nei cosiddetti file di risorse, i quali altro non sono che file di testo con un’opportuna codifica, si possono specificare aspetto, dimensioni e colori anche del singolo componente (widget); l’unico problema è che risulta molto difficile, al contrario di Swing (come si vedrà), modificare la veste grafica di un’applicazione durante l’esecuzione della stessa, in quanto la configurazione specificata nei file di risorse viene letta soltanto in fase di partenza. 
La gestione degli eventi asincroni (es. input dall’utente come la pressione di un tasto) è effettuata tramite le callback. Una callback è una routine in C con una intestazione formale (prototipo) ben precisa: nel codice se ne passa l’indirizzo e l’evento associato ad un determinato componente, e il sistema provvederà ad eseguirla allo scatenarsi di quel preciso evento. 
Il codice scritto in Motif / Xt / Xlib è sostanzialmente portabile su qualunque piattaforma UNIX che rispetti il protocollo di X-Windows.

Microsoft Foundation Classes

Figura 2 - Schema della gerarchia di MFC nel contesto di un'applicazione Windows

MFC, di cui vediamo uno schema in Figura 2, è completamente OO: esiste, come in Java, il concetto di una classe capostipite di tutte le altre, e dotata di attributi e metodi molto generici: in Java essa si chiama semplicemente Object, in MFC CObject. Di base, è nata allo scopo di mascherare come wrapper le primitive dell’SDK (Software Development Kit) di Windows, il cui uso è piuttosto macchinoso anche per risolvere problemi relativamente semplici; un’applicazione scritta con MFC fornisce anche il supporto per la gestione completa del ciclo principale degli eventi. Per fare un parallelo con il sistema X-Windows, MFC svolge la funzione di Xt e Motif, appoggiandosi sull’SDK che si pone sullo stesso piano delle Xlib; in un programma OO scritto con le librerie della Microsoft l’uso dell’SDK sarà estremamente sporadico, se non  addirittura completamente da evitare. 
Da un punto di vista strutturale, i componenti delle GUI sono visti come altrettante classi legate fra loro da una complessa ma coerente gerarchia di ereditarietà; la libreria mette a disposizione anche una serie di classi di utilità e contenitori generici, quali stringhe, liste, etc.
Il codice scritto con MFC non è, almeno allo stato attuale, portabile su nessun’altra piattaforma diversa da Windows; le applicazioni che ne scaturiscono però sono veloci e compatte. Per questo motivo il binomio MFC + Visual C++ appare allo stato attuale come la migliore combinazione per ottenere buoni risultati e poter gestire applicazioni di una certa dimensione e a tutti i livelli di interazione con il sistema operativo. Ultimamente, tuttavia, il fiato di Visual Basic si fa sentire, essendo quest’ultimo probabilmente il modo più veloce per ottenere risultati funzionanti e gradevoli all’operatore, soprattutto in progetti medio-piccoli. 
Il sistema di gestione degli eventi è la versione object oriented delle callback di Motif. In questo caso, ogni classe ha alcuni metodi riservati (molti dei quali tramandati tramite ereditarietà) aventi nomenclatura convenzionale del tipo On<evento>; se lo sviluppatore è interessato a gestire un determinato evento, allora dichiara una sottoclasse del componente fornito dalla libreria (es. bottone), e provvederà a personalizzare il metodo implementandolo con codice opportuno.
Infine, MFC è strettamente integrata con altri package sviluppati dalla Microsoft stessa, che fornisce ampio supporto per i database e ODBC, per la comunicazione e lo scambio di dati anche via rete fra processi (COM/DCOM), etc. Quindi vi sono ottime potenzialità per creare applicazioni versatili e complete.

Swing

• AWT;
• 2D API;
• Accessibility API;
• Swing, su sui concentreremo la nostra attenzione.

Swing è scritta interamente in Java, quindi il codice è veramente indipendente dalla piattaforma; infatti non ne esiste una distribuzione per ogni sistema, come invece accade per il JDK, ma la medesima può essere utilizzata dappertutto. Un diagramma logico della struttura di Swing in relazione alle altre componenti del sistema è visibile in Figura 3, che si presta ad alcune considerazioni piuttosto interessanti.
 
 

Figura 3 - Architettura del sistema AWT-Swing nei confronti di un'applicazione e dello strato nativo del sistema

Innanzitutto, i componenti di Swing sono classificabili in due tipi distinti:
 

• Heavyweight (Componenti “pesanti”): sono pochi e i più fondamentali (Frame, Window, Dialog) e si chiamano così poiché in pratica sono gli stessi di AWT, che vengono mappati direttamente sul corrispondente componente nativo (denominato peer);
• Lightweight (Componenti “leggeri”): sono la maggior parte, e sono definiti estendendo AWT, che comunque già non li mappa direttamente sul componente nativo.

Conclusioni

Da questo confronto emerge senz’altro (se non ce ne fosse bisogno di ribadirlo!) che, almeno finora, le due librerie native sono indiscusse dominatrici ognuna nella rispettiva piattaforma, dal punto di vista della velocità di esecuzione, dimensione degli eseguibili e occupazione di risorse.
MFC è forse la migliore combinazione per ottenere buoni risultati sotto Windows specie per progetti medio-grandi per la capacità di sfruttare le potenzialità del C++, e rappresenta un notevole (ma obbligato) passo avanti nei confronti dell’SDK di Windows; tuttavia, grazie alla sua intuitività d’uso Visual Basic sta incalzando. Sono degne di una seppure breve nota le librerie sviluppate dalla Borland (ora Inprise) per Windows, prima ObjectWindows (sulle varie versioni di Borland C++ a partire dalla versione 3.1), e poi la libreria che è il cuore dell’odierno C++ Builder; si tratta in ambedue i casi di ottimi prodotti, cui il mercato però non ha riservato il successo che avrebbero meritato.
Il trio Xlib/Xt/Motif è un ambiente che ha dalla sua parte la solidità ormai provata e il supporto alla comunicazione client-server, con prestazioni ottime su tutte le piattaforme UNIX; tuttavia, risente del design un po’ antiquato e il fatto che non sia veramente object-oriented ne ha forse un po’ appannato lo smalto.
Che dire di Swing? Dal punto di vista della flessibilità, configurabilità e delle scelte di carattere progettuale è sicuramente la migliore delle tre. Questo è dovuto sia alla sua giovane età, che ha permesso l’applicazione di concetti emersi soltanto in tempi piuttosto recenti, e sia al fatto che Java è intrinsecamente un ottimo linguaggio orientato agli oggetti che per molti aspetti costituisce un indubbio passo avanti rispetto al C++ per chiarezza e pulizia del codice. 
Naturalmente, Swing non è esente da problemi. Innanzitutto, il suo design innovativo richiede uno sforzo di comprensione iniziale senz’altro superiore alle altre due librerie. Più importante ancora, il linguaggio Java stesso e Swing a maggior ragione sono ancora tecnologie giovani, che solo recentemente hanno cominciato ad assestarsi, perciò i bachi sono ancora numerosi e le performance ancora molto deludenti; la lentezza è notevole e l’occupazione di memoria anche di un ordine di grandezza superiore ad un programma nativo con le stesse funzionalità. E’ chiaro che in un futuro molto prossimo le migliorie apportate e l’aumento di potenza di calcolo a parità di costi renderanno Swing e Java ancora più appetibili. Questi ultimi affiancheranno senza offuscarle le proprie potenzialità a quelle dei linguaggi nativi, nel perseguimento del duplice obiettivo di migliore comodità per lo sviluppatore e migliore qualità e versatilità delle applicazioni per l’utente finale.
 
 
 
 

Bibliografia 

[ 1 ] D. Young, The X-Window System – Programming and Applications with Xt (Motif Edition), ed. Prentice-Hall PTR
[ 2 ] Vari, The Xlib Programming Guide, ed. O’ Reilly
[ 3 ] Vari, The Xlib Reference Guide, ed. O’ Reilly
[ 4 ] Vari, The Xt Intrinsics Programming Guide, ed. O’ Reilly
[ 5 ] Vari, The Xt Intrinsics Reference Guide, ed. O’ Reilly
[ 6 ] Sito Internet: www.motifzone.com

Considerata per scontata la conoscenza del linguaggio Java, ci limitiamo a indicare alcuni riferimenti su AWT e Swing:
[ 7 ] D. Geary, Graphic Java 2- Mastering the JFC, Vol.I – AWT, ed. Prentice-Hall PTR
[ 8 ] D. Geary, Graphic Java 2- Mastering the JFC, Vol.II – Swing, ed. Prentice-Hall PTR
[ 9 ] Sempre di D. Geary e SUN, nella stessa colonna dei due precedenti si segnalano Vol.III – Advanced Swing, e Vol. IV – 2D API, anche se il loro raggio d’azione si spinge al di la’ dell’ambito del presente articolo.
[ 10 ] M. Campione, K. Walrath et al., The Java Tutorial (Sezioni AWT e Swing), disponibile su Internet da www.javasoft.com
[ 11 ] B. Eckel, Thinking in Java, ed. Prentice-Hall PTR
[ 12 ] M. Carli, Corso di Swing su Mokabyte (1998-1999), distribuito su vari numeri di Mokabyte e disponibili anche per download da www.mokabyte.it
[ 13 ] Sito Internet di JavaSoft su Swing, www.javasoft.com/jfc, e la sua sottosezione The Swing Connection (www.javasoft.com/jfc/tsc), ricca di documentazione, aggiornamenti e articoli tecnici.

Sull’argomento Design Patterns si consigliano i seguenti due testi:

[ 14 ] E. Gamma et al. (“Gang of Four”), Design Patterns, ed. Addison-Wesley
[ 15 ] M. Grand, Design Patterns in Java - Vol. 1, ed. Wiley

alcuni riferimenti sulla programmazione in Windows, Visual C++ e le Microsoft Foundation Classes:

[ 16 ] . Vari, Microsoft Visual C++ Library Reference (VC++ 5.0), Vol. 1 e 2, ed. Microsoft Press 
[ 17 ] J. Prosise, Programming Windows with MFC, ed. Microsoft Press
[ 18 ] C. Petzold, Programming Windows: The Definitive Guide to the Win32 API, ed. Microsoft Press
[ 19 ] D. Chapman, Visual C++ 6 – Guida Completa, ed. Apogeo