Al momento dell'inizializzazione del progetto Glade costruisce un albero di directory e files (o links a files) che permettono allo sviluppatore esperto di trovarsi con una buona base di partenza ed a quello principiante di intuire quali sono i passi che ci si aspetta che compia prima di un rilascio.
Un progetto Glade é diviso in più files e in più directory. Un progetto generico si trova quindi ad avere la seguente struttura:
I files che contengono i sorgenti creati da Glade sono quattro e di norma hanno i seguenti nomi:
Alcuni di questi files sono sovrascritti da Glade (interface.c, support.c e i relativi .h), cioé Glade li genera ex-novo ad ogni salvataggio del progetto. Quindi durante la costruzione della GUI questi files non devono essere modificati manualmente dall'operatore.
In seguito, a GUI ultimata, questi files potrebbero essere modificati dall'operatore che può trovare molto comodo interagire direttamente con il codice della GUI. Purtroppo questo apparente guadagno si paga rinunciando all'uso di Glade per le eventuali future modifiche. Personalmente ho trovato davvero comodo mantenere la compatibilità dei miei sorgenti con Glade e dove mi era necessario sono intervenuto a modificare la GUI in run-time senza modificare i files generati da Glade.
Un esempio banale é quello di voler cambiare titolo ad una finestra di dialogo a seconda che si usi per aprire o salvare i files. In questo caso é sufficiente associare ad una variabile globale (inizializzata dalla funzione apri o salva) il puntatore ad un testo che si vuole inserire come titolo e aggiungere un signal-handler collegato con l'evento di creazione o di visualizzazione della finestra di dialogo files.
L'approccio di modifica in run-time della GUI ha però il difetto di richiedere al programmatore una conoscenza un poco più approfondita del funzionamento delle GTK+ e dell'uso dei segnali di quanto non comporti la modifica diretta del codice.
La creazione di una GUI mediante l'uso di Glade é fatta di alcuni passi grosso modo obbligatori. Descrivere la sequenza pur senza entrare nei particolari é utile per la fase preliminare di progetto.
Ogni programma dovrebbe iniziare con un progetto carta & penna e, nel nostro caso, sapere quali sono i punti da soddisfare per ottenere una generica GUI funzionante ci mettono in grado di fare questo progetto almeno per quanto riguarda l'interfaccia grafica:
Come potete capire il momento della progettazione dell'interfaccia grafica condizionerà lo sviluppo che si vorrà dare in seguito al programma o viceversa nel caso il programma esista già, magari a riga di comando, sarà quest'ultimo a dettare le regole per la costruzione dell'interfaccia grafica.
Mentre i primi tre punti sono tutto sommato un fatto di costruzione mediante componenti già fornite da Glade/GTK+ eventualmente utilizzando le estensioni Gnome il quarto punto é invece assai più complesso per via delle interazioni che i vari segnali/eventi posso avere.
La generazione di un dato evento, che chiamerò per distinguerlo padre, potrebbe (anzi molto spesso avviene) generare l'emissione di altri segnali figli il che comporta alcuni problemi di fondo:
A questi inconvenienti si può ovviare disattivando alcuni signal-handler durante il running di altri signal-handler oppure di loro stessi per impedire il richiamo in molteplici istanze. In ogni caso sarebbe opportuno per programmi complessi studiare un sistema che funzioni da incodatore sequenziale di eventi (del tipo FIFO: First Input First Output) e che in casi particolarmente intricati sappia gestire anche le dipendenze/precedenze di un signal-handler rispetto all'altro (congelando l'esecuzione di alcuni).
Personalmente sono incappato in simili inconvenienti pur sviluppando un programma abbastanza semplice come Rubrica Italiana. Voglio però rassicurare quelli che vogliono approfondire in prima persona la conoscenza con Glade/GTK+/C che tali inconvenienti si sono manifestati solo nella gestione dinamica dell'interfaccia e comunque per risolverli é stato sufficiente carta & penna alla mano buttar giù un diagramma degli eventi e semplificarlo (perché sono le soluzioni semplici quelle che davvero funzionano ;-).
Un altro punto che si deve tenere sotto controllo é quello che riguarda le interazioni con il windows-manager. Ad esempio l'utente decide di chiudere l'applicazione con il tasto [X] della finestra piuttosto che con il vostro -menù chiudi- e come risultato ottiene che il windows-manager killa l'applicativo senza nemmeno chiedergli di salvare i suoi preziosi dati. In questo caso, ad esempio, é sufficiente catturare l'evento di destroying della finestra con un signal-handler che provveda secondo le circostanze.