Tutorial Librerie Qt Parte 1

Transcript

1 Tutorial Librerie Qt Parte 1 Premessa Questo tutorial è rilasciato sotto Licenza Creative Commons: Attribution-NonCommercial-NoDerivativeWorks ( Questo documento può quindi essere riprodotto senza violare nessuna legge, sia in versione elettronica, sia in versione cartacea, purché sia riprodotto integralmente in tutte le sue parti, compresa la pagina che contiene queste informazioni: Versione originale scaricabile dal sito Tutti i marchi riportati in questa pubblicazione appartengono ai rispettivi proprietari. Cosa sono le librerie Qt Qt è contemporaneamente una libreria di classi C++ ed un insieme di strumenti per lo sviluppo di interfacce utente grafiche (GUI) multi piattaforma, e' conosciuto infatti anche con il nome di toolkit Qt. Sviluppato dalla norvegese Trolltech, Qt permette lo sviluppo software secondo la filosofia write once, compile anywhere, che significa letteralmente scrivi una sola volta e compila ovunque. In altre parole, Qt permette agli sviluppatori di scrivere codice sorgente perfettamente compilabile su diversi sistemi operativi, quali ad esempio MS Windows, Mac OS X, Linux, Solaris, HP-UX, molte versioni UNIX con grafica X11 ed embedded Linux. Cio' e' stato reso possibile grazie all'adozione di un'interfaccia di programmazione delle applicazioni (API) unica ed indipendente dall'hardware e dal software di sistema. Insieme con la libreria di classi, vengono forniti strumenti di supporto per il design grafico (Qt Designer), per la traduzione linguistica (Qt Linguist) e il manuale in linea (Qt Assistant). Molte distribuzioni Linux (tra le maggiori troviamo Debian, SuSE, RedHat) contengono il toolkit Qt, esso è la base su cui è stato costruito l'intero desktop environment KDE ed è stato integrato sin dall'inizio nell'ide di riferimento per il mondo KDE, ovvero Kdevelop. Qt è attualmente usato in molti campi per applicazioni sia open source, sia commerciali. Gli esempi più famosi citati dalla stessa Trolltech, sono Adobe Photoshop Album (elaborazione ed archiviazione immagini), Skype (comunicazioni VoIP) e Scribus (editing e desktop publishing). Breve storia Il toolkit Qt fu inizialmente sviluppato dai fondatori della Trolltech, Haavard Nord ed Eirik Chambe Eng. Lo sviluppo di un toolkit in C++ per la realizzazione di Graphical User Interface (GUI) iniziò nel 1988, per conto di un'azienda svedese, che commissionò il lavoro ai due ricercatori e due anni più tardi, venne completato lo sviluppo di un'applicazione per la gestione di una banca dati di immagini, ottenute da apparecchiature mediche ad ultrasuoni; poiché

2 questa applicazione doveva permettere l'esecuzione dell'interfaccia utente su sistemi MS Windows, Mac e UNIX, gettò le basi di quello che oggi è uno dei punti di forza di Qt: la portabilità del codice sorgente su diverse piattaforme o, come si dice correntemente, lo sviluppo cross-platform. Nel 1991 si iniziò a scrivere le prime classi di Qt a seguito dell'idea di implementazione del meccanismo di Signals&Slots, un semplice ma potente modo per far comunicare tra loro le classi del toolkit. Nel 1993, dopo aver trascorso due anni a lavorare sul progetto senza contratti e senza stipendio, Haavard ed Eirik resero disponibile il primo kernel grafico e decisero di entrare in affari presentando al mondo il miglior GUI toolkit in C++ multipiattaforma. Il 1994 non iniziò nel migliore dei modi e si dovette attendere sino ad aprile 1995 per avere il primo contratto; il nome Qt venne scelto perché la lettera 'Q', tra i caratteri disponibili su Emacs, piaceva ad Haavard e la lettera 't' venne aggiunta per rappresentare la parola inglese toolkit (letteralmente l'insieme di strumenti di lavoro). Il 20 maggio venne rilasciata la versione 0.90 del toolkit e resa disponibile su sunsite.unc.edu, sei giorni dopo venne annunciata sul newsgroup comp.os.linux.announce. Questa fu la prima release pubblica di Qt, essa poteva essere usata sia per lo sviluppo di interfacce grafiche per MS Windows, sia per Linux ed offriva le stesse API su entrambe le piattaforme. Qt fu reso disponibile secondo due licenze d'uso sin dal primo giorno: la licenza commerciale serviva per lo sviluppo di applicazioni commerciali o close source e la free software edition per lo sviluppo di applicazioni open source. Nel marzo 1996, l'agenzia spaziale europea (ESA) divenne il secondo cliente della Trolltech e da questo momento iniziò un periodo che portò in breve tempo al rilascio della versione 0.97 (maggio), della versione 1.0 (settembre) e prima della fine dell'anno si giunse alla versione 1.1 usata da otto diversi clienti. Nell'aprile 1997 il fondatore del progetto KDE, Mattias Ettrich decise di adottare Qt per il suo progetto e, con il rilascio della versione 1.2, il toolkit Qt divenne lo standard de facto per la realizzazione di GUI in C++ per Linux. Nel 1998, Mattias decise di entrare a far parte del team di sviluppatori Trolltech (attualmente ricopre il ruolo di vice presidente) e contribuì al rilascio della versione 2.0. Questa versione conteneva un gran numero di cambi nell'architettura e rappresentò un notevole balzo in avanti nella realizzazione di un toolkit stabile e maturo; vennero aggiunte quaranta nuove classi, tra cui il supporto per l'unicode e nell'agosto del 1999 vinse il LinuxWorld award come miglior libreria software. L'anno 2000 segna l'ingresso sul mercato dell'ambiente Qt/embedded, concepito appositamente per supportare la piattaforma Linux/embedded. In quell'anno, Trolltech decise di cambiare la sua politica di licenza da QPL (politica open source appositamente redatta dalla Trolltech) a favore della ben più nota ed accettata GPL. Questo cambiamento venne accolto con entusiasmo dalle comunità open source (KDE per prima) di tutto il mondo. Il nuovo attesissimo balzo in avanti avvenne nel 2001 con il rilascio della versione 3.0. Qt era ora disponibile per MS Windows, UNIX, Linux, Embedded Linux e Mac OS X. Qt 3.0 aggiunse quarantadue nuove classi e il codice superò le linee. Dal 2001 al 2005 si è passati attraverso numerose minor releases che hanno fatto del toolkit Qt un mito tra gli sviluppatori (open source e non) di tutto il mondo, sia per le eccellenti caratteristiche tecniche del prodotto, sia per la politica di rilascio del prodotto aperta e lungimirante. KDE e Qt La potenza di Qt è di fondamentale importanza per KDE, il desktop environment di Linux è stato infatti costruito su questa libreria. Il ricco repertorio di widgets (oggetti grafici di interfaccia utente) e la quantità di classi offerte da questo toolkit (ad esempio la gestione dei caratteri UNICODE, interfacciamento verso database, gestione protocolli TCP ed UDP) ha fornito agli sviluppatori KDE un substrato intellettuale su cui basare l'intera architettura software. La filosofia di Qt è stata ripresa ed estesa, sino a consentire a KDE di offrire classi, oggetti grafici e plugins agli sviluppatori applicativi. Oggi, uno sviluppatore Qt/KDE ha a disposizione una collezione di componenti software estremamente ricca e performante per sviluppare la sua applicazione. In altre parole, se è valido il detto che buoni programmatori scrivono buoni programmi ed eccellenti programmatori rubano codice eccellente, allora Qt e KDE offrono le migliori condizioni per questo furto, grazie alla filosofia open source ed alla licenza GPL. Trolls contro Gnomi La storia vissuta dai programmatori KDE non è stata però molto facile all'inizio, il fatto di usare

3 le librerie Qt che nella versione 1.1 non erano disponibili con licenza GPL, scatenò le ire della comunità open source, in particolare Richard Stallman si scagliò in prima persona contro il loro impiego. Celebri infatti sono le sue parole sul tema KDE e Qt: Il disegno di KDE è stato basato su un errore fondamentale: l'uso della libreria Qt, che allora era software non-libero. Malgrado le buone intenzioni degli sviluppatori di KDE e malgrado il fatto che il codice di KDE in sè fosse software libero, KDE non poteva mai fare parte di un sistema operativo completamente libero. Per arginare il pericolo derivante dall'affermarsi di un desktop environment non-libero, sulla sua piattaforma libera GNU/Linux, Stallman si mosse attivamente per cercare un'antagonista al progetto KDE e lo trovò nel progetto GNOME, il GNU desktop. Dall'anno della sua fondazione, 1997, sino al 1999 (e ancor oggi), GNOME fu una spina nel fianco per i programmatori KDE; chi ha seguito le vicende dei due progetti, ricorda ancora le battaglie sui newsgroup a colpi di post e le reciproche accuse di filoeuropeismo (KDE) e filoamericanismo (GNOME). Per un lungo periodo, KDE venne visto come un tentativo di indipendenza tecnologica europea nei confronti degli stati uniti. A seguito di queste polemiche, nel 1999 Qt venne rilasciato sotto una nuova licenza, la QPL, che risolveva di fatto i problemi ma rimaneva sostanzialmente incompatibile con la GPL. Lo stato giuridico del KDE rimaneva quindi ancora appannato. Trolltech pose fine a questo problema rilasciando sotto GPL il suo toolkit; dalla versione Qt 2.2 infatti, la licenza adottata è appunto la GPL. Dai giorni delle battaglie fra Trolls e Gnomi di tempo ne è passato e KDE è oggi riconosciuto ed apprezzato dalla comunità open source mondiale ed è stato inserito nelle distribuzioni Linux più pure e fedeli al movimento open source. La questione della doppia licenza Oggi, Qt viene offerto sulla base di un modello a doppia licenza; in altre parole, gli sviluppatori software che vogliono donare il codice sorgente da essi scritto alla comunità open source, possono scaricare ed usare la versione open source edition liberamente, e scrivere con esso applicazioni senza subire alcuna restrizione. L'unico vincolo che dovrà quindi essere rispettato è quello di rilasciare il codice sorgente in accordo con quanto prescritto dalla licenza GPL e quindi, in estrema sintesi, permette a chiunque di copiare, modificare e redistribuire l'applicazione. L'esempio più conosciuto di applicazione open source realizzata con Qt è sicuramente il desktop environment KDE. Gli sviluppatori che vogliono invece realizzare applicazioni proprietarie o close source, devono acquistare una licenza commerciale per ogni postazione di lavoro, scegliendo quella più adatta alle proprie esigenze progettuali. Trolltech infatti, prevede tre possibili licenze, ciascuna caratterizzata da prestazioni e costi differenti. Qt console rappresenta la versione per lo sviluppo embedded senza GUI, Qt Desktop light è invece la versione di base per lo sviluppo di applicazioni con GUI, ma senza supporto per rete ed SQL ed infine, Qt Desktop la versione completa. Perchè usare Qt Per sistemi UNIX, Qt rappresenta un'ottima possibilità, è portabile, è veloce, facile da imparare ed usare, inoltre, se si scrive software open source per Linux, BSD, Solaris o molte altre varianti UNIX, Qt è gratuito. In altre parole, non si deve pagare alcuna licenza. In caso contrario, se si sviluppa codice commerciale, occorre acquistare una licenza per lo sviluppo (ma non si dovrà pagare alcuna royalty per ogni applicazione venduta). Supponiamo che si voglia scrivere software commerciale closed source per la piattaforma Windows, per quale motivo si dovrebbe usare Qt, per il mondo Windows esistono già diversi ambienti di sviluppo commerciali e diversi toolkit GUI? La risposta a questa domanda può arrivare se si pensa alla portabilità. Scrivere applicazioni con Qt permette infatti di portare il codice sorgente scritto anche su altre piattaforme, sarà sufficiente la ricompilazione e la nostra applicazione potrà essere eseguita in modo nativo sulla nuova piattaforma. Portabilità Un toolkit che permetta lo sviluppo di GUI multi-piattaforma, deve implementare una strategia per nascondere al programmatore i dettagli dovuti alle API native del sistema operativo sottostante. Esistono fondamentalmente tre strategie differenti adatte allo scopo e prendono il nome di API layering, API emulation e GUI emulation. La strategia di API layering (letteralmente stratificazione delle API), prevede la costruzione di

4 una nuova API fornita da uno strato software che viene localizzato al di sopra della API nativa. I vantaggi offerti da questa soluzione sono una relativa semplicità di programmazione ed una totale conformità con il look&feel (aspetto estetico) nativo. Per contro lo svantaggio principale è dovuto alla lentezza dei programmi scritti, basandosi sulle nuove API; infatti lo strato software aggiuntivo va ad appesantire l'esecuzione con inevitabili rallentamenti. La strategia di API emulation (letteralmente emulazione della API), consiste nell'emulare le API di un unico sistema su tutte le altre piattaforme. In questo caso, non occorre innestare uno strato software al di sopra delle API native per la piattaforma emulata, occorre bensì inserirla per le altre piattaforme, diverse da quella usata come riferimento. Benché questa soluzione sembri risolvere i problemi di portabilità, in realtà è difficile da ottenere, in quanto se le piattaforme sono tra loro troppo differenti, l'uso di una API di riferimento è molto complicato da realizzare. La terza strategia è quella adottata da Qt e consiste nell'emulare il vero comportamento di una GUI; per fare ciò, vengono usate solamente le primitive grafiche di base, offerte da ciascuna piattaforma, quali ad esempio le funzioni per tracciare un punto, una linea, un cerchio. Il vantaggio di questa soluzione è evidente, non si appesantisce l'applicazione con uno strato software aggiuntivo e neppure si devono uniformare tutte le API dei sistemi su cui garantire la portabilità. Lo svantaggio principale di questa soluzione è dovuto al fatto che l'emulazione della GUI deve essere fatta in modo da eguagliare il più possibile il look&feel della piattaforma nativa ed inoltre, quando anche solo un nuovo widget (componente di GUI) viene aggiunto o modificato su una piattaforma, il toolkit deve essere aggiornato e riemesso (la possibilità di modifiche o aggiunte ai widget grafici di una piattaforma consolidata è comunque un evento assai raro). La GUI emulation permette quindi al toolkit Qt di emulare il comportamento di ogni singola GUI per ogni sistema operativo supportato e di fornire quindi al programmatore un ambiente unico, svincolato dalla piattaforma su cui verrà eseguito, basandosi su un'unica API che nasconde i dettagli sottostanti. Per portare un'applicazione da una piattaforma ad un'altra, sarà sufficiente ricompilare il codice sorgente sulla nuova piattaforma e mandare in esecuzione il codice eseguibile generato. Installare il Qt toolkit per Linux La versione del tookit che adotteremo per questa serie di articoli è l'ultima rilasciata dalla Trolltech relativa alla serie Qt 3, ovvero la versione La scelta è caduta su questa versione, poichè essa è disponibile su molte distribuzioni Linux essendo la componente base del desktop KDE. Qualora la vostra distribuzione preferita non la contenesse o voleste aggiornare la versione in vostro possesso, dovete per prima cosa recarvi sul sito FTP della Trolltech ftp://ftp.trolltech.com/qt/source/ oppure un sito mirror e scaricare il seguente file compresso gzip qt-x11-free tar.gz, oppure in alternativa il file qt-x11-free tar.bz2. A questo punto potete posizionarvi nella directory dove volete installare il file, copiate l'archivio compresso e scompattatelo con i comandi seguenti cd /usr/local gunzip qt-x11-free tar.gz tar xf qt-x11-free tar A questo punto troverete la directory qt-x11-free La cosa da fare ora è impostare le variabili di ambiente. Se la shell che usate è bash, ksh, zsh o sh, aggiungete le seguenti linee nel vostro.profile nella vostra home directory QTDIR=/usr/local/qt-x11-free PATH=$QTDIR/bin:$PATH MANPATH=$QTDIR/doc/man:$MANPATH LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH export QTDIR PATH MANPATH LD_LIBRARY_PATH Se invece la vostra shell è csh o tcsh, aggiungete le seguenti linee nel vostro.login file setenv QTDIR /usr/local/qt-x11-free setenv PATH $QTDIR/bin:$PATH setenv MANPATH $QTDIR/doc/man:$MANPATH setenv LD_LIBRARY_PATH $QTDIR/lib:$LD_LIBRARY_PATH

5 Ora siete pronti per configurare il toolkit semplicemente eseguendo i comandi cd $QTDIR./configure Ricordate che per ottenere la lista completa delle opzioni possibili per configure è sufficiente digitare il comando./configure -help Dopo aver eseguito configure, potete compilare il toolkit digitando il comando make Al termine della compilazione, il vostro Qt toolkit sarà pronto per l'uso. Installare il toolkit per Windows Sul sito Trolltech l'ultima versione non commerciale del toolkit Qt3 non è reperibile, è possibile invece trovare una versione open source su sourceforge: Dopo aver scaricato il file setup-qt-win-free-mingw exe in una directory di lavoro, lanciare l'esecuzione del programma auto installante. Occorre ricordare che tale versione richiede il compilatore MINGW, un porting del gcc per sistema operativo Windows. Installare il Qt toolkit per MAC L'installazione del toolkit per Mac avviene da una finestra terminale. Per lanciare un terminale, potete cercare in Application/Utilities con Finder. Per prima cosa recatevi sul sito FTP della Trolltech ftp://ftp.trolltech.com/qt/source/ oppure un sito mirror e scaricate il file compresso gzip qt-mac-free tar.gz. A questo punto copiate il file in /Developer e scompattatelo con il comando tar zxf qt-mac-free tar.gz Create un collegamento simbolico alla directory qt, mediante il comando ln -sf qt-mac-free qt In base alla shell che usate, dovrete impostare le variabili in modo differente. Se la shell che usate è bash, ksh, zsh o sh, aggiungete le seguenti linee nel vostro.profile nella vostra home directory QTDIR=/Developer/qt PATH=$QTDIR/bin:$PATH MANPATH=$QTDIR/doc/man:$MANPATH DYLD_LIBRARY_PATH=$QTDIR/lib:$DYLD_LIBRARY_PATH export QTDIR PATH MANPATH DYLD_LIBRARY_PATH Se invece la vostra shell è csh o tcsh, aggiungete le seguenti linee nel vostro.login file setenv QTDIR /Developer/qt setenv PATH $QTDIR/bin:$PATH setenv MANPATH $QTDIR/doc/man:$MANPATH setenv DYLD_LIBRARY_PATH $QTDIR/lib:$DYLD_LIBRARY_PATH Ora siete pronti per configurare il toolkit semplicemente eseguendo i comandi cd $QTDIR./configure Ricordate che per ottenere la lista completa delle opzioni possibili per configure è sufficiente digitare il comando./configure -help Dopo aver eseguito configure, potete compilare il toolkit digitando il comando make Ora occorre rendere eseguibili le vostre applicazioni attraverso finder. Se, nella compilazione del toolkit avete specificato l'opzione static, allora tutte le vostre applicazioni (tra cui i tools di Qt) conterranno le librerie dentro il codice eseguibile e quindi saranno visibili con Finder, altrimenti, in caso di librerie dinamiche (compilazione di default), occorre creare due link simbolici per permettere il collegamento dinamico. I collegamenti sombolici saranno attivati con i comandi seguenti: ln -sf $QTDIR/lib/libqt.3.dylib /usr/lib ln -sf $QTDIR/lib/libgui.1.dylib /usr/lib

6 Per eseguire questi comandi possono essere necessari i diritti di accesso come amministratore, in tal caso si può eseguire: sudo ln -sf $QTDIR/lib/libqt.3.dylib /usr/lib sudo ln -sf $QTDIR/lib/libgui.3.dylib /usr/lib In caso non si disponga dei diritti di amministratore o si voglia installare Qt localmente, si possono eseguire i seguenti comandi: ln -sf $QTDIR/lib/libqt.3.dylib $HOME/lib ln -sf $QTDIR/lib/libgui.1.dylib $HOME/lib Descrizione dei tools Qt non è solamente una libreria, ma come dice il nome stesso, un insieme di tool che consentono e facilitano lo sviluppo con la libreria stessa. Tra i tools messi a disposizione, abbiamo il Qt Designer (comando Linux : designer) Si può affermare con sicurezza che questo è lo strumento più famoso dell'intero toolkit, esso viene impiegato non solo per disegnare graficamente le interfacce utente di un'applicazione, bensì può essere considerato un vero e proprio ambiente di sviluppo integrato per scrivere un'intera applicazione. A partire dalla versione Qt 2.0, designer è cresciuto da semplice editor grafico ad ambiente di lavoro completo in grado di gestire files di progetto, modelli di interfacce utente ( templates), consentire editing del codice sorgente di applicazione e può essere facilmente esteso mediante plugins per l'aggiunta di nuovi componenti grafici (custom widgets). Qt Assistant (comando Linux : assistant)

7 Questo strumento presenta la ricca documentazione on-line fornita a corredo di Qt, sia in versione commerciale, sia in versione open source. Esso è di fatto un browser della documentazione dotato delle funzioni classiche di navigazione (indietro di un passo, avanti di un passo, vai a home, stampa pagina corrente) con in più, la gestione di una funzione di ricerca per parola, la riserca su indice e la possibilità di inserire bookmarks. La documentazione fornita non si limita alla spiegazione delle classi, bensì è un vero e proprio manuale d'uso del toolkit con spiegazione dei tools, del funzionamento interno del toolkit stesso, fornisce preziose informazioni per lo sviluppatore riguardo le licenze, le risorse in rete, gli add-on ed ha una sezione tutorial ed examples utile sia a chi muove i primi passi con Qt, sia agli utenti più smaliziati. Qt Linguist (comando Linux: linguist)

8 Questo è lo strumento usato per gestire la traduzione linguistica delle applicazioni Qt. L'internazionalizzazione di un'applicazione software Qt avviene in tre fasi, per prima cosa occorre lanciare il tool lupdate su tutti i files sorgenti che necessitano di traduzione; al termine della sua analisi, lupdate produrrà un file contenente tutte le stringhe testuali da tradurre. Questo file, verrà utilizzato da linguist per gestire il processo di traduzione. Qt Linguist è infatti un'interfaccia per il traduttore dotata di funzioni avanzate, quali la possibilità di associare commenti alle stringhe da tradurre e traduzione automatica, qualora le parole contenute in una frase da tradurre siano già state tradotte in precedenza. A seguito della fase di traduzione, il tool lrelease provvederà alla creazione di uno o piu' files binari contenenti le stringhe tradotte, il numero di files generato è dovuto alla quantità di lingue supportate. Questi files verranno caricati dall'applicazione qt durante l'avvio e verranno utilizzati come vocabolario per la visualizzazione delle stringhe testuali nella lingua selezionata. User Interface Compiler (comando Linux: uic) UIC è lo strumento che traduce i files.ui generati da designer (sintassi XML) in codice C++. Meta Object Compiler (comando Linux: moc) Il meta object compiler è lo strumento che partendo dalle classi C++ generate dallo UIC, crea i meta oggetti C++, necessari al funzionamento e alla comunicazione tra le classi della nostra applicazione. Qt make (comando Linux: qmake) Un'applicazione Qt è composta dai files sorgenti, dalle librerie, dai files generati dallo UIC e dal MOC e dai files di internazionalizzazione. L'esigenza di mantenere il codice portabile su diverse piattaforme, porta alla creazione di un numero elevato di files e di conseguenza aumenta rapidamente la complessità del makefile. Lo scopo di qmake è appunto quello di semplificare la gestione di un progetto, nascondendo i dettagli legati al sistema operativo. A titolo di esempio, viene qui di seguito presentata la sequenza di comandi da eseguire per generare il makefile di un semplice progetto Qt. Per prima cosa occorre portarsi nella directory contenente i files sorgenti della nostra applicazione e da lì digitando il comando qmake-project si richiede al Qt make di eseguire l'analisi di tutti i files contenuti nella directory. A seguito di questa analisi, qmake produrrà il file di progetto con estensione.pro da usare successivamente per la creazione del makefile vero e proprio. Digitando qmake nome_file_generato.pro si otterrà la creazione del file makefile da usare

9 per creare la nostra applicazione, in altre parole, digitando il comando make -f makefile o semplicemente make, avvieremo il nostro make sul file makefile lanciando automaticamente tutti i tools (ad esempio uic, moc, gcc) necessari a generare il nostro eseguibile. Riassumendo, le operazioni da compiere sono: qmake -project qmake nome_file_generato.pro make Signals&Slots L'intero meccanismo di meta object system, è stato inventato dai programmatori della Trolltech (detti anche Trolls, richiamando le antiche figure della mitologia norvegese a cui si attribuivano poteri magici) per consentire agli utenti del toolkit di scrivere il proprio codice sorgente, senza doversi perdere nei dettagli del sistema operativo sottostante. Il punto cruciale a cui i Trolls dovevano trovare soluzione, era quello di far comunicare tra loro gli oggetti C++ della loro libreria, senza per questo dover dipendere dai metodi di comunicazione nativi (quali ad esempio la gestione degli eventi di MS Windows o di X11), in modo da rimanere indipendenti dall'implementazione. Prima di addentrarci nell'analisi del meccanismo di comunicazione adottato da Qt (chiamato Signals&Slots), cerchiamo di capire in cosa consiste il problema. Supponiamo di avere una finestra di dialogo contenente due oggetti grafici molto semplici, un bottone ed un indicatore visivo (immaginiamo, a titolo di esempio, qualcosa di simile alla lampada di un semaforo, di colore rosso) e supponiamo inoltre di voler dotare la nostra finestra di una semplice funzionalità: quando viene eseguito un click del mouse sul bottone grafico (in altre parole, il bottone viene premuto ), il colore del nostro semaforo diventa verde. Il semplice esempio sopra riportato, ci pone di fronte al problema di far comunicare tra loro i nostri due oggetti grafici: il pulsante ed il semaforo; in altre parole, quando il pulsante viene premuto, deve essere emesso un segnale al semaforo, in modo che esso possa riconoscere l'evento e cambiare colore. In estrema sintesi, il nostro problema di comunicazione può essere descritto con le parole di segnale, corrispondente all'evento di bottone premuto e cambio colore, funzione propria dell'oggetto grafico semaforo, innescata dal segnale di bottone premuto (usando la terminologia Qt, questo è uno slot ). Allo stato attuale delle cose, abbiamo identificato un segnale ed uno slot, ciò che ancora ci manca è un metodo per il loro collegamento. Il meccanismo di meta object system di Qt, ci viene in soccorso offrendoci una funzione (connect), indipendente dalla piattaforma, per realizzare questa connessione. La breve introduzione fatta al meccanismo di Signals&Slots, ci consente di capire l'importanza fondamentale che esso riveste nella programmazione Qt; ciò che invece non è ancora stato chiarito è perché questo meccanismo deve essere indipendente dalla piattaforma. Per poter apprezzare il lavoro svolto dai Trolls, gettiamo una rapida occhiata su altri due GUI toolkits molto famosi: Motif ed MFC. Per entrambi i toolkits, il sistema di gestione delle finestre sottostante (X-Window per Motif e MS Windows per MFC), fornisce al software applicativo, indicazioni molto primitive delle interazioni con l'utente. Ad esempio, le informazioni riportate possono essere del tipo: l'utente ha premuto il tasto T, oppure, l'utente ha premuto il bottone sinistro del mouse alle coordinate 320, 320. Come si può capire, partendo da queste informazioni basilari, costruire un'applicazione dotata di interfaccia uomo macchina molto complessa, richiede un tempo notevole ed inoltre tenere sotto controllo un numero elevato di dettagli di basso livello, dovuti alla natura della piattaforma sottostante, è spesso causa di errori e inevitabilmente si traduce in tempi di sviluppo (e debugging) molto lunghi. L'esigenza di semplificare la programmazione della piattaforma grafica (il window manager) ha portato quindi alla creazione dei due toolkits prima citati, che sono divenuti nel tempo il riferimento per il mondo Windows e il mondo UNIX. Ciascun toolkit ha presentato la propria soluzione ai problemi tipici di programmazione di una interfaccia grafica e come spesso accade, nessuno sforzo è stato compiuto per uniformare i due ambienti. Come risultato, abbiamo ora due toolkits grafici completamente svincolati e incompatibili tra loro, per cui scrivere un'applicazione per entrambi i sistemi operativi (MS Windows e UNIX-Motif) richiede la stesura di due interfacce utenti completamente diverse, con grande spreco di risorse per lo sviluppo (e il test). Per dare un esempio tangibile di questa diversità, vediamo come è stato risolto dai due toolkits

10 il problema della comunicazione e vedremo infine come è stato risolto il problema dai Trolls in modo elegante e platform-independent (indipendente dalla piattaforma). Motif implementa la comunicazione tramite il meccanismo detto a callback. Le callback sono funzioni C, dotate di argomenti di chiamata predefiniti e vengono registrate (in pratica si registra il puntatore alla funzione callback da chiamare a fronte di un evento del mouse) all'interno di ogni componente grafico (o widget, nella terminologia Motif). Chiaramente, ogni widget Motif, deve riconoscere un preciso numero di callback, così come deve conoscerne il tipo e tutti i parametri (compreso il tipo dei parametri stessi), tornando al nostro esempio di partenza, un bottone Motif riconoscerà quindi le funzioni di callback per gli eventi di pressione, rilascio e click del mouse. Supponiamo ora che un bottone Motif venga premuto, il codice al suo interno andrà a verificare di quale evento si tratta, lo riconoscerà e chiamerà la funzione di callback associata o meglio la chiamerà usando il suo puntatore a funzione (il cui indirizzo è stato memorizzato in precedenza durante l'operazione di registrazione). Lo svantaggio principale di questa implementazione è che se la funzione callback (scritta dal programmatore applicativo e quindi situato sopra il toolkit stesso) non è perfettamente in linea con quanto si attende il toolkit, supponiamo ad esempio che un parametro sia un array e che il numero di elementi non sia uguale tra quanto si attende il toolkit e quanto è stato scritto dal programmatore applicativo, allora l'applicazione potrebbe bloccarsi e andare in crash (sappiamo infatti che i compilatori C non eseguono controlli sulle dimensioni degli array). MFC impiega invece delle macro precostruite per realizzare il collegamento tra gli eventi forniti dal gestore delle finestre, chiamati anche messaggi nella terminologia Windows, con i metodi C++ (che sono praticamente funzioni callback) per la gestione degli eventi. Uno degli svantaggi principali che tutti i programmatori MFC hanno sperimentato è la complessità del message system di MS Windows, anche quando ci si avvale degli ambienti di sviluppo integrato e dei wizards per la creazione di finestre di dialogo basandosi su templates. Come si può constatare, il problema della comunicazione è stato risolto dai due toolkits in due modi tra loro differenti; in estrema sintesi possiamo dire che, in un caso si ricorre a puntatori a funzione (Motif), nell'altro ci si appoggia a macro per collegare i messaggi di MS Windows ai metodi C++ di gestione degli eventi (MFC). L'esempio riportato è solamente uno dei tanti problemi che un programmatore di GUI deve affrontare quando dal program management dell'azienda per cui lavora, arriva la fatidica frase portiamo la nostra applicazione su quest'altro sistema operativo!. Questo problema, viene velocemente ed elegantemente risolto se si adotta Qt. Dopo aver analizzato come avviene la comunicazione tra oggetti con Motif ed MFC, vediamo ora come è stato risolto il problema dai nostri Trolls. Signals&Slots in pratica Gli slots sono praticamente identici alle funzioni membro di una classe, si può quindi parlare di slots pubblici, privati e protetti secondo l'accezione classica del linguaggio C++ e possono essere invocati così come avviene per tutti gli altri metodi tradizionali di una classe. La differenza sostanziale è che uno slot, può sempre essere collegato ad un segnale e quindi sarà invocato ogni volta che il segnale verrà emesso. Questo collegamento signal/slot, viene realizzato con la funzione di libreria connect ed ha la sintassi: connect (sender,signal(signal),receiver,slot(slot)); dove sender e receiver sono i puntatori agli oggetti Qt (nel nostro esempio sender è il bottone e receiver il semaforo) da porre in comunicazione e signal, slot sono funzioni (in questo caso senza parametri) appartenenti rispettivamente all'oggetto sender e receiver. Nel caso invece di collegamento signal/slot con 1 parametro intero si avrà: connect (sender,signal(signal(int)),receiver,slot(slot(int))); La macro SIGNAL() e la macro SLOT() sono essenziali per il funzionamento del tutto e verranno pre-processate dal meta object compiler (moc) prima della compilazione di tutti i files del progetto. Il meta object system di Qt è quindi un passo di pre-processing in grado di generare codice C++ puro, partendo dalla definizione degli oggetti Qt. In questo modo, il meccanismo signal&slot, potrà funzionare su qualsiasi sistema operativo, l'unica condizione necessaria è

11 quindi la disponibilità di un compilatore C++ standard (quale ad esempio gcc). L'uso di moc e qmake libera quindi il programmatore da tutti i dettagli di implementazione necessari al funzionamento multipiattaforma del meccanismo signals e slots. Così come esiste una funzione connect, esiste anche la funzione opposta, la disconnect, usata per disconnettere il segnale dallo slot precedentemente collegati. La sintassi della funzione è: disconnect (sender,signal(signal),receiver,slot(slot)); In questo modo è possibile attivare e disattivare il collegamento tra oggetti a run-time. Va inoltre ricordato che più segnali possono essere collegati ad uno stesso slot, un segnale può essere collegato a più slots ed infine un segnale può essere collegato ad un altro segnale: connect (sender,signal(signal1),receiver,slot(signal2)); In questo caso, quando viene emesso il segnale signal1, verrà anche emesso il segnale signal2. Due parole sul C++, cosi' come viene usato da Qt Per essere sicuri che la nostra competenza di C++ sia sufficiente per la programmazione delle librerie, facciamo un piccolo ripasso dei concetti principali che ci saranno utili nella lettura dei prossimi articoli; come detto, si tratta di una semplice rassegna di concetti che incontreremo nella nostra presentazione, questo non vuol essere un tutorial C++ esaustivo e dettagliato. Classi Trattandosi di una libreria di classi, Qt fa chiaramente uso di classi. Il linguaggio C++ fornisce la possibilità di creare nuove classi nello stesso modo in cui permette di creare nuovi tipi, possiamo affermare che una classe è un nuovo tipo definito dall'utente. Gli oggetti di una classe vengono creati ed inizializzati mediante funzioni proprie dichiarate esplicitamente a questo scopo, tali funzioni prendono il nome di costruttori. Una funzione propria di una classe può anche avere lo scopo di cancellare ogni oggetto di una classe quando questa viene distrutta, questa seconda funzione prende il nome di distruttore. Una classe può quindi essere vista come un nuovo tipo, caratterizzato di informazioni interne, dette anche proprietà ed un insieme di operazioni ristretto e ben definito (metodi) per agire su di esse. In altre parole consideriamo una classe come una scatola nera in cui le operazioni su di essa avvengono solamente attraverso quell'insieme di operazioni. Un esempio tipico di classe può essere una tabella, che poi è l'elemento base su cui si costruiscono tutte le applicazioni di tipo foglio elettronico, essa presenterà almeno un'operazione (detto anche metodo) di inserimento, un metodo per verificare se un particolare elemento è stato inserito, alcuni metodi di ordinamento ed infine un metodo per eliminare uno o più elementi della tabella. La documentazione di corredo fornita con il toolkit Qt, illustra nei dettagli e fornisce inoltre alcuni esempi di utilizzo della classe tabella (QTable). Occorre inoltre ricordare che è sempre possibile ottenere l'indirizzo di un oggetto, questo permette quindi di applicare tutte le regole sui puntatori già viste nel linguaggio C. Qt fa largo uso di puntatori ad oggetti, in particolare nel passaggio di parametri. Per convenzione, i nomi delle classi Qt sono rappresentativi della classe stessa e iniziano tutti con la lettera Q maiuscola (ad esempio le classi QApplication, QPushButton). Derivazione di classi Un concetto importante della programmazione ad oggetti, ovvero la derivazione di classi, sta alla base della programmazione Qt. Derivare una classe è un meccanismo semplice, flessibile ed efficiente per definirne una nuova, partendo da una esistente ed aggiungendo ad essa nuovi metodi e proprietà. Il concetto di derivazione di classi è ampiamente impiegato quando si vogliono realizzare custom widgets, ossia controlli grafici che partendo da quelli di base offerti da Qt, introducono nuove funzioni e comportamenti. Metodi di accesso Qt fa pesantemente uso dei metodi di accesso, i quali non sono altro che metodi per accedere alle proprietà interne di un oggetto (metodi get) o impostarle (metodi set). Per convenzione i nomi dei metodi di accesso sono rappresentativi della funzione svolta ed iniziano con le parole get (dal verbo To Get, ovvero, ottenere) e set (dal verbo To Set, impostare). Un esempio che

12 possiamo citare è il metodo setmainwindow, che sarà il primo metodo che impareremo ad usare nel nostro esempio di fine articolo. Funzioni virtuali Le funzioni virtuali consentono ai programmatori di dichiarare funzioni in una classe base che possano essere ridefinite in ogni classe derivata. Qt usa le funzioni virtuali per inviare notifica degli eventi, provenienti dal sistema di gestione delle finestre, agli oggetti che compongono l'interfaccia utente. Overloading di operatori Qt esegue l'overload di alcuni operatori, ad esempio è possibile passare come parametro la classe QString (classe Qt incaricata di gestire le stringhe testuali), a tutte quelle funzioni che si aspettano come parametro const char*. In questo caso, esisterà un operatore che automaticamente convertirà il parametro di tipo QString nel parametro puntatore const char*. Vediamo ora una semplice applicazione che riassume quanto visto sin'ora. Applicazione di esempio Lo scopo di questa applicazione è duplice; se da un lato si vuol mostrare quali sono i passi da seguire per produrre il codice eseguibile, dall'altro lato si vuole concretizzare quanto è stato detto sul meccanismo di Signals&Slots. La nostra applicazione non farà altro che mostrare una semplice finestra di dialogo contenente un bottone che, una volta premuto, chiuderà la finestra terminando il programma stesso. Il codice sorgente dell'applicazione è il seguente: /***********************************************************/ /* Nome File : main.cpp */ /* Descrizione: esempio di funzionamento Signals&Slots */ /***********************************************************/ #include <qapplication.h> #include <qpushbutton.h> int main(int argc, char *argv[]) { QApplication app(argc,argv); QPushButton *button = new QPushButton( Esci, 0); button->connect(button,signal(clicked()), &app, SLOT(quit())); app.setmainwidget(button); button->show(); return app.exec(); } Per prima cosa dobbiamo includere gli header files <qapplication.h> e <qpushbutton.h>, in quanto QApplication e QPushButton saranno le prime classi Qt che andremo ad usare. La prima istruzione di codice C++ che incontriamo è QApplication app(argc,argv); istanzia un oggetto app di tipo QApplication, che è appunto la classe Qt che rappresenta il nostro intero programma. Al costruttore app() vengono passati gli argomenti provenienti dalla linea di comando, nel nostro caso non servono, ma è buona regola inserirli sempre, per poter avere la possibilità di gestirli automaticamente tramite la libreria Qt (si pensi ad esempio agli argomenti passati da linea di comando per impostare su quale X terminal eseguire il display di una nostra applicazione).

13 A questo punto possiamo inserire il nostro primo widget Qt nella finestra di dialogo che verrà creata automaticamente da app, per fare ciò scriveremo la linea di codice QPushButton *button = new QPushButton( Esci, 0); Tramite la new, andiamo ad istanziare dinamicamente un oggetto button, partendo dalla classe QPushButton fornitaci dalla libreria Qt, che è una classe è molto importante e viene usata praticamente ovunque in qualsiasi interfaccia utente. Questa classe è caratterizzata da un gran numero di proprietà, quali ad esempio il testo che compare al centro del bottone, il colore di sfondo, il colore del testo e molte altre ancora ed inoltre fornisce un elevato numero di metodi richiamabili pubblicamente, come ad esempio il metodo per cambiare la stringa di testo o il colore, oppure metodi più specializzati, come ad esempio il metodo connect(), necessario per implementare una connessione. La documentazione in linea fornita con il toolkit (richiamabile da prompt con il comando assistant) fornisce una spiegazione veramente completa riguardo la classe, la lista completa e dettagliata dei metodi, delle proprietà, degli eventi che essa genera (pressed, clicked, released) ed inoltre fornisce alcuni esempi pratici di utilizzo. Nel nostro esempio andremo ad allocare dinamicamente un oggetto, il cui puntatore è memorizzato nella variabile button e passeremo al costruttore di classe due parametri, di cui il primo è la stringa di caratteri che verrà visualizzata al centro del bottone ( Esci ) e il secondo rappresenta il puntatore al widget padre del nostro bottone. Nel nostro caso vogliamo che il bottone sia un oggetto top level e quindi forniremo un puntatore nullo per indicare che non esiste un oggetto padre. Esempi di oggetti figli verranno approfonditi nei prossimi articoli quando introdurremo la gestione del layout di finestra, per il momento ci limitiamo ad un semplice bottone. La prossima istruzione ci porta esattamente al cuore del nostro esempio; il nostro scopo è quello di capire come si realizza una connessione e quindi come funziona il meccanismo di Signals&Slots e qui ne vediamo l'implementazione. button->connect(button,signal(clicked()),&app, SLOT(quit())); Per poter capire nel dettaglio il metodo connect(), occorre prima chiarire alcune cose. Il metodo connect che andiamo ad impiegare ci viene fornito direttamente dalla classe QPushButton, questo è infatti il significato della chiamata button->connect(). Il primo parametro passato è il puntatore all'oggetto sender, cioè quell'oggetto che invia il segnale, nel nostro caso è il puntatore button. Il secondo parametro rappresenta il segnale emesso, ovvero clicked(), ma dovremo ricordarci di informare il meta object system di Qt, tramite la macro SIGNAL; come regola pratica, quando all'interno della connect, scriviamo i parametri di signal e slot, dovremo sempre ricordarci di passarli non direttamente, bensì tramite le macro forniteci da Qt SIGNAL e SLOT. Il parametro seguente è il puntatore all'oggetto ricevente che, nel nostro caso è &app (ricordiamo che app non è stata allocata dinamicamente tramite una new e quindi di essa non abbiamo il puntatore all'oggetto, bensì l'oggetto stesso). Infine, come ultimo parametro, passeremo il metodo (o meglio lo slot) che vorremo richiamare sull'evento di clicked del mouse. Useremo quindi lo slot quit() fornitoci da QApplication, incaricato di chiudere l'applicazione e distruggere tutte le risorse grafiche ad essa associate. La nostra applicazione quindi terminerà dopo il click del mouse sul bottone e ol farà grazie a questa istruzione di connect. A questo punto, tramite l'istruzione app.setmainwidget(button); andremo ad informare la nostra applicazione che la risorsa grafica principale (nel nostro caso anche unica) sarà il bottone. Come risultato, Qt creerà un contorno di finestra (con i pulsanti standard di minimizzazione, massimizzazione e chiusura) per il nostro bottone. L'istruzione button->show(); non è altro che la chiamata al metodo show(), fornito da tutti i widget Qt e necessario per abilitarne la visualizzazione sul display. Occorre infatti ricordare che quando un oggetto viene istanziato (ad esempio con l'operatore new), esso non viene visualizzato sul display; esiste ma e' nello stato invisibile. Questa è la strategia adottata da tutti i toolkits, sia per il mondo X-Window, sia per MS Windows e Mac. In realtà, se ci fermiamo un attimo a riflettere, comprendiamo per quale motivo questa strategia è corretta. Per prima cosa si può affermare che, in linea di principio, la creazione di un oggetto è un'operazione logicamente separata dalla sua visualizzazione ed inoltre, in molti casi può risultare estremamente comodo visualizzare un widget in un momento successivo alla sua creazione. L'ultima istruzione di un programma realizzato con la libreria Qt sarà sempre

14 return app.exec(); Tramite il metodo exec(), fornitoci dalla classe QApplication, andiamo ad avviare l'applicazione stessa e quindi le forniremo la possibilità di intercettare gli eventi da tastiera, da mouse o i segnali di terminazione di sistema (come ad esempio il comando kill di un processo). Due parole sulla classe QApplication La classe QApplication gestisce sia il flusso di esecuzione di una applicazione GUI, sia l'impostazione dei suoi principali parametri. Essa contiene il ciclo principale di gestione degli eventi (conosciuto in gergo informatico con il termine main event loop), responsabile di processare e distribuire gli eventi provenienti dal gestore di finestre (Windows o X-Windows per Linux). QApplication è inoltre responsabile della fase di inizializzazione e terminazione dell'applicazione; nella nostra semplice applicazione infatti, vediamo come sia possibile impiegare gli argomenti passati da linea di comando per comunicare con l'applicazione stessa, senza per questo doversi preoccupare di effettuare il parsing degli argomenti stessi. In definitiva, le aree di responsabilità di QApplication sono: Inizializzare l'applicazione con le impostazioni utente di desktop, quali ad esempio il font, la palette o l'intervallo di tempo per il doppio click del mouse. Gestire gli eventi provenienti dal sistema di gestione a finestre sottostante e distribuirle ai widgets coinvolti dall'interazione utente. Questo meccanismo di gestione consente inoltre la generazione di eventi proprietari, definiti dal programmatore, da mandare ai widgets mediante il metodo di sendevent(). Eseguire il parsing degli argomenti passati da linea di comando ed impostare di conseguenza lo stato interno dell'applicazione. Gestire la clipboard. Gestire il cursore del mouse. Gestire la sessione. Questo ad esempio permette la corretta terminazione dell'applicazione nel caso di log out della sessione. Poiché QApplication è responsabile di tutte le inizializzazioni, la creazione di questo oggetto dovrà avvenire prima di ogni altra cosa. Tornando alla nostra applicazione, vediamo infatti che l'oggetto app viene creato per primo. Come si fa una buona GUI Come già accennato, Qt è divenuto il toolkit di riferimento nella realizzazione di interfacce utente, ma esso da solo non basta per realizzare una buona GUI. Un buon designer dovrà infatti affiancare alla conoscenza tecnica degli strumenti in suo possesso, la capacità di prevedere ogni esigenza dell'utente ed una particolare abilità nel rendere semplice ed intuitiva la sua interfaccia. Unitamente a tutto ciò, dobbiamo sempre ricordare che anche l'occhio vuole la sua parte... e quindi un po' di creatività e senso estetico possono fare la differenza. In più casi abbiamo assistito al successo di un'applicazione mediocre, ma dotata di eccellente interfaccia utente, nei confronti di applicazioni potenti ma troppo complicate da usare. Per aiutare il designer/programmatore nel suo difficile compito, illustreremo qui di seguito alcune linee guida da osservare quando si realizza un'interfaccia utente. Per prima cosa, occorre sempre provare per alcuni minuti l'applicazione che stiamo realizzando, se qualcosa ci risulta scomodo o difficile da ricordare, lo sarà maggiormente per chi userà il nostro software senza conoscere come è stato fatto. La nostra applicazione dovrà essere concepita per poter essere usata sia dall'utente casuale, sia dall'utente più smaliziato. Fornire acceleratori da tastiera o altri mezzi per una rapida navigazione, può essere apprezzato dagli utenti più esperti, ma occorre sempre fornire una guida o altri strumenti di aiuto per chi si appresta ad usare l'applicazione per la prima volta. I widgets grafici adottati, dovranno essere selezionati con attenzione tra quelli a disposizione. Nulla può essere più frustrante per un utente che dover usare dei widgets non appropriati per il compito che vuole svolgere. Si pensi ad esempio a quale sarebbe l'impatto di usare uno spinbox per impostare una data. In molti casi si dovrebbe scorrere l'intera lista di possibilità, prima di poter trovare il numero che ci interessa! Selezionare i widgets più adatti richiede ovviamente una conoscenza approfondita del toolkit e dei suoi meccanismi di controllo. In alcuni casi, il widget non esiste ed allora si rende necessario crearne uno nuovo, questa è la situazione in cui i migliori programmatori danno il meglio di loro stessi. Creare un custom widget non è operazione banale, in quanto occorre una grande competenza tecnica per addentrarsi nella programmazione più a basso livello del toolkit ed occorre una buona abilità nel saper disegnare un oggetto grafico nuovo, il cui comportamento risolva nel migliore dei modi un'esigenza mai affrontata in precedenza. Widgets grafici di aspetto simile devono eseguire operazioni simili; questo per non confondere chi usa l'applicazione. Quando un widget non è attivo a causa dello stato della vostra applicazione è bene disabilitarlo o nasconderlo. La vostra applicazione dovrà sempre fornire una risposta immediata alle azioni utente, lunghe attese prima di

15 ricevere un segnale di vita spazientiscono gli utenti o, ancor peggio, creano l'ansia da crash dell'applicazione. Occorre essere pronti per l'internazionalizzazione della vostra applicazione sin da subito. Qualora il vostro software avesse successo e voleste esportarlo in altri paesi è meglio non doverlo riscrivere da zero, dedicando così del tempo ad un'operazione poco creativa e soggetta ad errori. Qt offre un meccanismo di internazionalizzazione molto semplice; adottarlo sin da subito costa poca fatica e ci può risparmiare molto lavoro in futuro. Quando possibile, affidatevi agli standard già esistenti. Ad esempio, per chiudere un'applicazione è meglio inserire nella vostra barra dei menù la parola Esci (o Exit) ed impiegare la parola Chiudi (o Close) per indicare la chiusura di un documento precedentemente aperto dalla vostra applicazione. Questo è infatti lo standard che si è affermato su tutti i sistemi grafici più usati (MS Windows, X-Window, Mac). L'utente deve sempre essere supportato, l'uso dei tool tips (letteralmente strumenti di aiuto), ovvero le stringhe testuali che compaiono vicino al mouse quando il cursore viene posizionato nelle vicinanze di un controllo grafico (si pensi ad esempio ad un bottone o ad un elemento di una barra menù), dovrebbero sempre essere impiegate. Qt è di grande aiuto per la gestione dei tool tips con la classe QAction, responsabile di gestire le interazioni utente. Così come ogni altra stringa testuale presente nella vostra applicazione, anche i tool tips dovranno essere pronti per l'internazionalizzazione. Le informazioni di supporto all'utente, così come le richieste di conferma per le operazioni da eseguire non devono essere ossessive. Ad esempio, attivare due volte una finestra di messaggio per richiedere la conferma di una cancellazione, possono far innervosire l'utente. Fate sentire il vostro utente protetto, ma non stupido. Applicazione finale La nostra applicazione finale ci permetterà di imparare ad usare la classe QMainWindow offerta dal toolkit Qt. Questa classe consente di visualizzare una finestra principale e dotarla di tutte le funzionalità richieste da un'applicazione, gestiremo quindi una barra menù, una barra di stato che ci informerà sullo stato della nostra pplicazione e ci fornirà il tool tip ogni volta che il cursore del mouse passerà su un comando. La nostra applicazione ci permetterà di caricare da disco i file di immagine nei formati più comunemente utilizzati e di eseguire su di essi alcune semplici elaborazioni.

16 Applicazione finale Conclusioni In questo primo articolo abbiamo iniziato ad intravedere le potenzialità del Qt toolkit. Nel prossimo tutorial impareremo ad usare il Designer per creare velocemente le nostre applicazioni ed affronteremo un argomento importante ed articolato: il layout management. Tutte le GUI infatti sono composte da numerosi oggetti grafici che devono essere posizionati in modo intelligente ed intuitivo per essere facilmente utilizzabili; il posizionamento dei componenti grafici dentro una GUI viene gestito da Qt tramite il layout manager. Impareremo inoltre come rendere funzionale un'interfaccia grafica tramite il meccanismo degli eventi e la sua manipolazione. Per riassumere i concetti creeremo infine una finestra di dialogo in grado di visualizzare una immagine caricata da file. Con il terzo articolo dedicato a Qt, impareremo ad usare i principali widget grafici e a costruirne di nuovi (custom widget). L'ultimo articolo di questa serie ci vedrà impegnati nella realizzazione di una vera e propria applicazione per visualizzare immagini caricate da file, nei più diffusi formati digitali. Come ottenere aiuto Ottenere aiuto sull'uso del Qt toolkit è molto facile, per prima cosa la documentazione fornita a corredo del toolkit stesso è molto completa e di facile consultazione. Qualora non bastasse, esistono in Internet molte fonti di informazione. Un buon punto di partenza possono essere le mailing lists proposte dalla stessa Trolltech. Visitando il sito ci si può iscrivere oppure ottener maggiori informazioni. Le principali mailing lists a cui può essere utile iscriversi sono

17 qt-announce Iscriversi a questa mailing list permette di ricevere tutti gli annunci ufficiali della Trolltech riguardo Qt e gli altri prodotti (Qt, pur essendo il prodotto di bandiera, è solo uno dei diversi prodotti disponibili) Per iscriversi o cancellarsi da questa mailing list si può inviare un messaggio all'indirizzo qt-announce-request@trolltech.com contenente le parole subscribe (iscrizione) o unsubscribe (cancellazione) indifferentemente nell'intestazione o nel corpo del messaggio. Qt-interest Questa mailing list è un forum di discussione per utenti Qt, quindi molto utile per indagare se qualcuno ha già avuto (e risolto) un problema simile al nostro. L'archivio storico dei messaggi inviati su questa mailing list è reperibile sul sito Trolltech all'indirizzo Per iscriversi o cancellarsi da questa mailing list si può inviare un messaggio all'indirizzo qt-interest-request@trolltech.com contenente le parole subscribe (iscrizione) o unsubscribe (cancellazione) indifferentemente nell'intestazione o nel corpo del messaggio. Questa mailing list è inoltre disponibile come network news tramite il protocollo NNTP all'indirizzo news://nntp.trolltech.com/trolltech.qt-interest/. Snapshot-users Questa è una mailing list dedicata alle discussioni relative agli snapshots rilasciati dalla Trolltech. Uno snapshot è in pratica il rilascio di una versione di lavoro aggiornata quotidianamente e messa a disposizione della comunità. Chi vuole usarla per rimanere sempre allo stato dell'arte, può installarsi una versione nuova ogni giorno, deve però tener presente che la versione non è testata e può contenere errori. Per iscriversi o cancellarsi da questa mailing list si può inviare un messaggio all'indirizzo snapshot-user-request@trolltech.com contenente le parole subscribe (iscrizione) o unsubscribe (cancellazione) indifferentemente nell'intestazione o nel corpo del messaggio.