[english version (newest - più aggiornata)]
Il mio primo linguaggio di
programmazione è stato il BASIC, l'unico disponibile sul Sinclair
ZX Spectrum. Mi sono dedicato poi all'assembler Z80.
Quando sono passato ai PC, ho proseguito con il GwBasic e poi il QuickBasic. In tutti questi dialetti del Basic, la grafica era molto diversa, ma sempre presente.
Ho imparato a programmare in C negli anni, prima per hobby e poi a scuola, dedicandomi sempre e solo a funzioni algoritmiche, soprattutto perché la libreria standard del C purtroppo non contempla funzioni di grafica e nemmeno ha funzioni per la gestione delle finestre. Recentemente ho promosso anche una petizione per questo.
Quando Microsoft presentò Windows, già con la versione 1, ma poi la 3.1, i programmi in QBasic giravano in finestra e non mi preoccupai. Il C lo stavo ancora imparando e non mi resi conto che gli mancava la grafica. Del resto il C è nato per la programmazione di sistema, dove servono le prestazioni, per cui la grafica è all'opposto, sempre la parte lenta.
Con il rilascio di Win95, WinNT4 e poi di Linux, abbandonai sempre più il Basic e mi concentrai solo sul C per la potenza, le prestazioni che offriva e per via dei molti limiti nella gestione della memoria del QuickBasic. Subito dopo ho cominciato ad apprezzare una grande caratteristica unica del C, la sua portabilità tra tutte le architetture, indipendenza dal sistema operativo e dal microprocessore (x86, ppc, sparc, alpha, ...) usato sulla macchina. Ricordo di aver anche comprato a quell'epoca una copia di VisualBasic3 in licenza studenti, ma non l'ho mai nemmeno installata.
Su DOS e WinNT ho sempre usato il compilatore djgpp, un porting del gcc per MS-DOS. Su Linux il gcc è installato di serie. Per motivi di lavoro poi il gcc è diventato il compilatore di fiducia anche su altri sistemi operativi come HPUX, Solaris, OSF, VxWorks, ecc... ma sempre nella parte algoritmica o CLI, mai GUI, dal momento che sviluppavo driver per VxWorks e Linux.
In anni recenti su 2000/XP ho sempre usato il porting del gcc compreso in Cygwin, che fornisce un layer di emulazione di un sistema GNU Posix completo anche su piattaforma Win32 che ne sarebbe sprovvista.
Intorno al 2005 ho cominciato a sentire la necessità di fare dei grafici per alcune funzioni matematiche, o di fare dei semplici disegni con il linguaggio C.
Abituato com'ero a poter compilare per qualsiasi architettura tutti i miei programmi C, mi pareva troppo limitativo imparare qualcosa di mono piattaforma. Ho visto che c'erano diverse librerie grafiche per il disegno di linee, punti e grafici matematici, ma tutte unicamente per piattaforme Unix, oppure c'era la libreria GDI di Microsoft (usata dal VisualBasic e VisualC) ma solo per Windows.
In pratica cercavo una libreria C crossplatform per il disegno e la realizzazione di applicazioni GUI. Ho cominciato a cercare le soluzioni disponibili. Ho certamente escluso le GDI e le DirectX perché funzionanti solo su Windows. Una volta imparate, mi sarei trovato con una tool spuntato, da usare su una sola piattaforma, inutile per il mio lavoro, e magari se in futuro Windows sparirà, inutile anche come conoscenza personale.
Nel mondo Unix esistevano due soluzioni mature: le librerie QT di KDE portate avanti dalla Trolltech, e le GTK di GNOME portate avanti dalla comunità GNU. Di entrambe esiste il porting per Win32 e per MacOS, ma quello delle QT è in licenza commerciale a pagamento. Un'altra soluzione valida sono le WxWidgets, in licenza open su tutte le piattaforme. Ho cercato di capire quale delle tre soluzioni fosse meglio per me, quale avesse maggiori possibilità di sopravvivere, quale fosse migliore.
Cercando in giro ho notato che sono molto di più i progetti grossi, famosi e crossplatform (Mozilla, Gimp, Ethereal/Wireshark, Gaim/Pidgin, Inkscape, ...) scritti per le GTK rispetto alle altre due librerie, probabilmente perché GNOME è portato avanti dalla comunità GNU che vanta tantissimi sviluppatori, che vogliono prendere parte al processo decisionale. Inoltre GTK è nativa in C, mentre le altre due sono per il C++ che conosco poco. Mi sono dedicato allora a studiare il tutorial delle GTK. Imparati i rudimenti e i concetti base, si trattava di provare a compilare. A quell'epoca a casa tenevo in esecuzione principalmente Windows, e solo occasionalmente usavo Linux, soprattutto quando dovevo programmare, per via del miglior supporto offerto agli sviluppatori. Cygwin in tutte queste occasioni si è rivelato molto valido sopperendo alle carenze di Win32. Cygwin fornisce di serie anche le GTK per cui era abbastanza facile provare. Quando si è trattato di fare le finestre del tutorial tutto bene. Con applicativi anche un po' più complessi, realizzati con il GUI rapid developer Glade, ancora tutto bene, ma, tornando all'esigenza fondamentale di disegnare punti, linee e grafici di funzioni matematiche, si trattava di usare le funzioni di base su cui sono basate le GTK, le GDK.
In quel periodo le GTK ultima versione erano le 2.8, che non si basavano più per il disegno 2D e il rendering dei font unicamente su GDK, ma dalla 2.6 alla 2.8 erano migrate alla libreria grafica crossplatform Cairo. Fortunatamente in quel periodo ho conosciuto Luca, un collega del mio carissimo compagno di università Marco, che mi ha fortemente consigliato di imparare le Cairo per disegnare linee e punti, dato che l'orientamento della comunità di GTK e GNOME ormai era di usarle per tutto al posto di GDK.
Purtroppo Cygwin fornisce fino a tutto il 2007 le GTK2.6 che non si basano su Cairo. Si trattava quindi di integrare le ultime GTK in Cygwin. Ho cercato un po' in rete ma non ho trovato guide apposite. Chi usa Linux troverà banale compilare applicazioni GTK per Linux perché compilatori, librerie e ambiente di generazione sono forniti di serie. Su Windows invece niente è scontato perché, tanto per cominciare, il compilatore non è compreso nel prezzo. In rete inoltre trovate guide passo passo alla compilazione delle GTK su Linux. E troverete anche guide su come compilare le ultime GTK usando l'altro porting per Win32 del gcc, il MinGW/Msys, ma niente per Cygwin. Dopo un po di prove ho trovato la soluzione e sono riuscito a compilare le GTK2.12 con Cygwin, quindi ecco questa guida.
Primo metodo, pensato per utenti che conoscono Linux, e quindi preferiscono avere disponibili tutti i tool a cui sono abituati anche quando stanno usando Windows.
Guida alla compilazione con Cygwin di applicativi GUI crossplatform che usano GTK+ v2.8 e Cairo v1.4
Secondo metodo, pensato per utenti che conoscono solo Windows, e quindi troveranno particolarmente comodo un IDE per lo sviluppo
HowTo use Dev-C++ to compile GTK+ applications
Vai alla pagina EFA programmazione
Torna alla pagina principale:
EFA home page
Quando sono passato ai PC, ho proseguito con il GwBasic e poi il QuickBasic. In tutti questi dialetti del Basic, la grafica era molto diversa, ma sempre presente.
Ho imparato a programmare in C negli anni, prima per hobby e poi a scuola, dedicandomi sempre e solo a funzioni algoritmiche, soprattutto perché la libreria standard del C purtroppo non contempla funzioni di grafica e nemmeno ha funzioni per la gestione delle finestre. Recentemente ho promosso anche una petizione per questo.
Quando Microsoft presentò Windows, già con la versione 1, ma poi la 3.1, i programmi in QBasic giravano in finestra e non mi preoccupai. Il C lo stavo ancora imparando e non mi resi conto che gli mancava la grafica. Del resto il C è nato per la programmazione di sistema, dove servono le prestazioni, per cui la grafica è all'opposto, sempre la parte lenta.
Con il rilascio di Win95, WinNT4 e poi di Linux, abbandonai sempre più il Basic e mi concentrai solo sul C per la potenza, le prestazioni che offriva e per via dei molti limiti nella gestione della memoria del QuickBasic. Subito dopo ho cominciato ad apprezzare una grande caratteristica unica del C, la sua portabilità tra tutte le architetture, indipendenza dal sistema operativo e dal microprocessore (x86, ppc, sparc, alpha, ...) usato sulla macchina. Ricordo di aver anche comprato a quell'epoca una copia di VisualBasic3 in licenza studenti, ma non l'ho mai nemmeno installata.
Su DOS e WinNT ho sempre usato il compilatore djgpp, un porting del gcc per MS-DOS. Su Linux il gcc è installato di serie. Per motivi di lavoro poi il gcc è diventato il compilatore di fiducia anche su altri sistemi operativi come HPUX, Solaris, OSF, VxWorks, ecc... ma sempre nella parte algoritmica o CLI, mai GUI, dal momento che sviluppavo driver per VxWorks e Linux.
In anni recenti su 2000/XP ho sempre usato il porting del gcc compreso in Cygwin, che fornisce un layer di emulazione di un sistema GNU Posix completo anche su piattaforma Win32 che ne sarebbe sprovvista.
Intorno al 2005 ho cominciato a sentire la necessità di fare dei grafici per alcune funzioni matematiche, o di fare dei semplici disegni con il linguaggio C.
Abituato com'ero a poter compilare per qualsiasi architettura tutti i miei programmi C, mi pareva troppo limitativo imparare qualcosa di mono piattaforma. Ho visto che c'erano diverse librerie grafiche per il disegno di linee, punti e grafici matematici, ma tutte unicamente per piattaforme Unix, oppure c'era la libreria GDI di Microsoft (usata dal VisualBasic e VisualC) ma solo per Windows.
In pratica cercavo una libreria C crossplatform per il disegno e la realizzazione di applicazioni GUI. Ho cominciato a cercare le soluzioni disponibili. Ho certamente escluso le GDI e le DirectX perché funzionanti solo su Windows. Una volta imparate, mi sarei trovato con una tool spuntato, da usare su una sola piattaforma, inutile per il mio lavoro, e magari se in futuro Windows sparirà, inutile anche come conoscenza personale.
Nel mondo Unix esistevano due soluzioni mature: le librerie QT di KDE portate avanti dalla Trolltech, e le GTK di GNOME portate avanti dalla comunità GNU. Di entrambe esiste il porting per Win32 e per MacOS, ma quello delle QT è in licenza commerciale a pagamento. Un'altra soluzione valida sono le WxWidgets, in licenza open su tutte le piattaforme. Ho cercato di capire quale delle tre soluzioni fosse meglio per me, quale avesse maggiori possibilità di sopravvivere, quale fosse migliore.
Cercando in giro ho notato che sono molto di più i progetti grossi, famosi e crossplatform (Mozilla, Gimp, Ethereal/Wireshark, Gaim/Pidgin, Inkscape, ...) scritti per le GTK rispetto alle altre due librerie, probabilmente perché GNOME è portato avanti dalla comunità GNU che vanta tantissimi sviluppatori, che vogliono prendere parte al processo decisionale. Inoltre GTK è nativa in C, mentre le altre due sono per il C++ che conosco poco. Mi sono dedicato allora a studiare il tutorial delle GTK. Imparati i rudimenti e i concetti base, si trattava di provare a compilare. A quell'epoca a casa tenevo in esecuzione principalmente Windows, e solo occasionalmente usavo Linux, soprattutto quando dovevo programmare, per via del miglior supporto offerto agli sviluppatori. Cygwin in tutte queste occasioni si è rivelato molto valido sopperendo alle carenze di Win32. Cygwin fornisce di serie anche le GTK per cui era abbastanza facile provare. Quando si è trattato di fare le finestre del tutorial tutto bene. Con applicativi anche un po' più complessi, realizzati con il GUI rapid developer Glade, ancora tutto bene, ma, tornando all'esigenza fondamentale di disegnare punti, linee e grafici di funzioni matematiche, si trattava di usare le funzioni di base su cui sono basate le GTK, le GDK.
In quel periodo le GTK ultima versione erano le 2.8, che non si basavano più per il disegno 2D e il rendering dei font unicamente su GDK, ma dalla 2.6 alla 2.8 erano migrate alla libreria grafica crossplatform Cairo. Fortunatamente in quel periodo ho conosciuto Luca, un collega del mio carissimo compagno di università Marco, che mi ha fortemente consigliato di imparare le Cairo per disegnare linee e punti, dato che l'orientamento della comunità di GTK e GNOME ormai era di usarle per tutto al posto di GDK.
Purtroppo Cygwin fornisce fino a tutto il 2007 le GTK2.6 che non si basano su Cairo. Si trattava quindi di integrare le ultime GTK in Cygwin. Ho cercato un po' in rete ma non ho trovato guide apposite. Chi usa Linux troverà banale compilare applicazioni GTK per Linux perché compilatori, librerie e ambiente di generazione sono forniti di serie. Su Windows invece niente è scontato perché, tanto per cominciare, il compilatore non è compreso nel prezzo. In rete inoltre trovate guide passo passo alla compilazione delle GTK su Linux. E troverete anche guide su come compilare le ultime GTK usando l'altro porting per Win32 del gcc, il MinGW/Msys, ma niente per Cygwin. Dopo un po di prove ho trovato la soluzione e sono riuscito a compilare le GTK2.12 con Cygwin, quindi ecco questa guida.
Primo metodo, pensato per utenti che conoscono Linux, e quindi preferiscono avere disponibili tutti i tool a cui sono abituati anche quando stanno usando Windows.
Guida alla compilazione con Cygwin di applicativi GUI crossplatform che usano GTK+ v2.8 e Cairo v1.4
Secondo metodo, pensato per utenti che conoscono solo Windows, e quindi troveranno particolarmente comodo un IDE per lo sviluppo
HowTo use Dev-C++ to compile GTK+ applications
Vai alla pagina EFA programmazione
Torna alla pagina principale:
EFA home page