Problema 1: PyGtkGlext per Windows

Problema
Dove trovare PyGtkGlExt per Windows e Python 2.4?
Soluzione
Ho chiesto nella relativa mailing list e mi e' stato fornito il file, che credo possa mettere tranquillamente qui.
PyGtkGlExt 1.01 per Python 2.4 in Windows


C'e' voluto un po' per trovare PyGtkGlExt per Windows: intanto spiego cos'e'.
PyOpengl permette di aprirti una finestra e gestire il tuo mondo OpenGl li'.
A me serve gestire OpenGl in un riquadro di una piu' generica finestra GTK, nella quale vi siano contemporaneamente molti widget, menu', icone, ecc.
GtkGlExt permette (c'era anche GtkGlArea ma e' caduto in disuso) questa immersione all'interno di una finestra (gtk.Window), tramite i widget posso quindi interagire convenientemente e istantaneamente sul disegno.

GtkGlExt e PyGtkGlExt sono realizzati fondamentalmente per Linux, ma molti stanno cominciando a interagire anche con Windows, per cui ho speranze che queste librerie vengano aggiornate continuamente (per ora lo sono, ma comunque non e' necessario questo aggiornamento continuo).
In questo caso, poiche' il Python 2.4 e' abbastanza recente e il mantenitore ufficiale di PyGtkGlExt si e' un po' dileguato (ma nella mailing list c'e' qualcuno che continua ad aggiornare) ho dovuto cercare qualcuno che trovasse il modo di compilare in Windows e Visual Studio tali sorgenti (comunque sempre disponibili), ho cercato io stesso di compilare tali sorgenti.

Non riuscivo a compilarlo (non avendo Visual Studio usavo DevC++) in quanto mi restituiva un errore di compatibilita': Python e PyGtkGlExt dovevano essere stati compilati con lo stesso compilatore.
Credo che sbattendoci la testa il problema si sarebbe potuto comunque risolvere, ma perche' perderci tempo?

Documentazione

DECISIVI sono poi i newsgroup, nei quali ci sono programmatori che rispondono volontariamente alle domande e senza i quali non andrei da nessuna parte (magari piu' avanti daro' un contributo a qualcuno!).
I newsgroup che uso sono:

• it.comp.lang.python
• comp.lang.python
• comp.graphics.api.opengl
  

Prima di fare una domanda sarebbe d'uopo, secondo me,

• aver cercato prima con Google
• aver cercato una domanda simile sul newsgroup (a tal proposito il servizio Google Groups e' strepitoso)

In genere comunque qualcuno che risponde anche alle domande piu' balzane c'e' sempre, a volte si discute a livelli che vanno oltre alle tecnicita' del Python

Poi devo dire che mi piace Dive into Python che rimanda spesso alla giusta pagina della documentazione ufficiale e spiega passo passo: e' un buon tutorial.

Poi per le PyGtk mi piace http://www.parafernalia.org/pygtk/ che e' stato molto utile per realizzarele prime interfacce, che poi comunque costruisco piu' velocemente con Glade.
Conoscere un minimo le Pygtk e', secondo me (e molti altri a quanto leggo in giro), necessario, per capire come funzionano considerando che se poi con Glade servono comunque, per sapere come interagire con i widget "caricati" da libglade.

Per quanto riguarda le PyGtkGlExt mi sono stati utili gli esempi, coi quali si puo' capire subito come usare le relative API e farsi l'area da disegno sull'interfaccia.

Per quanto riguarda OpenGl, punto di riferimento che ho in questo momento e' OpenGl A primer, di Edward Angel (Second Edition), utile soprattutto per capire bene come usare il glOrtho o il gluPerspective, per capire le trasformazioni, le curve.
Credo pero' che alcuni dettagli manchino (ad esempio, come renderizzare in diversi riquadri contemporaneamente? La cosa mi servira' per creare un output ad alta definizione).

Introduzione

Il presente diario prevede l'inserimento di appunti, esperimenti, pensieri riguardo alle mie esperienze nel linguaggio Python, su cui ho messo le mani per la prima volta il 5 dicembre del 2005.
Tali appunti non sono pensati con scopo didattico, ma perche' tendo a dimenticare le cose, quindi mi serve un riferimento veloce per rirordare cose fatte qualche mese prima (e poi c'e' la casella di ricerca qui in cima molto utile).

In che ambito lo sto usando: sono uno studente universitario che deve fare un software per una societa'.
Tale software deve avere un ambiente grafico di disegno, un interfaccia a finestre, la possibilita' di stampare in postscript.
Uso quindi

1. per il disegno: librerie OpenGl con binding PyOpengl. La scelta ricade su questa libreria per la necessita' di prestazioni e per la portabilita' (ma e' un aspetto molto secondario) di tali librerie. Lo svantaggio principale: occorre creare tutta la modalita' di disegno (snap, trascinamenti, ecc) (Opengl: "Applications developers do not need to license the OpenGL API", PyOpengl: BSD License).
   


2. per l'interfaccia: librerie Gtk (GNU LGPL), con binding PyGtk (GNU LGPL)
. Anche tali librerie sono portabili (anche in C# ad esempio), ma soprattutto veloci e facili da capire e usare.

3. per la costruzione veloce dell'interfaccia: Glade costruisce un file XML (la licenza GPL di Glade non ha influenza sul file XML che genera), con la libreria libglade poi si carica questo file e si creano i widget precedentemente creati con Glade (libglade ha licenza GNU LGPL)


4. per inserire il disegno in un widget dell'interfaccia: libreria GtkGlExt con relativo binding PyGtkGlExt (licenza GNU LGPL)


5. per la stampa su file: libreria gl2ps che permette la creazione di un file postscript a partire da codice OpenGl (in poche parole "visualizzando" il normale output OpenGl su file). Le gl2ps sono scritte in C, per cui ho bisogno di Swig: un wrapper che permette di gestire codice C in Python e altri linguaggi (licenza di gl2ps: GNU LGPL, Swig: "free for commercial use")


6. per tutto il resto: Python

Sistema operativo utilizzato: Windows, perche' dove mi serve c'e' solo questo, e poi perche' comunque l'uso che se ne fara' e' previsto su macchine Windows

Piattaforma di sviluppo: Eclipse+PyDev, un plugin che permette la costruzione di progetti in Python. C'e' anche un diario anche per Pydev, ospitato su Blogspot.
Piccolo problema: Eclipse e' un mattone, ovunque l'ho messo non l'ho visto veloce.

Pydev manca (per quel che ho visto) di alcuni tool quali ad esempio quello per i creatori dei metodi accessori, cosa comunque facilmente programmabile. Inoltre la correzione degli errori non banali avviene quasi sempre successivamente all'esecuzione (ma Python e' un interprete, forse questo e' ovvio)