Innanzitutto grazie per le spiegazioni!<br><br>Da quanto hai scritto deduco che evidentemente mi hanno chiesto di sviluppare la GUI a "manina" (usando wxpython) perchè devo aggiungere al frame un canvas in cui inserire oggetti (immagini, testo) su cui realizzare a "manina" il drag and drop, lo zoom, applicare maniglie per ridimensionare gli oggetti, ecc. Tutto questo non si può fare con un GUI builder? <br>
<br>Inoltre hai scritto che solo in fase di costruzione della GUI il dover leggere a runtime un file xml da interpretare per creare la GUI richiede un po' di tempo di esecuzione in più rispetto ad una generazione "diretta" da codice.<br>
Ma ciò non è necessario nel corso della successiva esecuzione, perchè? Forse perchè nella successiva esecuzione in entrambi i casi ho il bytecode? <br><br>Perdonami ma sono all'inizio con python e GUI....<br>
<br><br>Dany<br><br><div class="gmail_quote">Il giorno 28 marzo 2009 13.31, Massimo Masson <span dir="ltr"><<a href="mailto:max@studiomasson.it">max@studiomasson.it</a>></span> ha scritto:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
danielita ha scritto:<br>
<div class="im">> Ok, è chiaro,<br>
> ma questo significa anche che:<br>
> realizzata la GUI con wxpython, quando l'utente finale utilizzerà la GUI<br>
> sarà tutto più veloce???<br>
<br>
</div>[...]<br>
<br>
Secondo me, gli strumenti che usi per costruire la GUI non hanno<br>
influenza alcuna sulla velocità di esecuzione (a parità di altre<br>
condizioni), ma solamente sui tempi di scrittura del codice.<br>
<br>
Scrivere "a mano" è solo più tedioso che lasciarlo fare ad un programma<br>
apposito (GUI builder). "A mano" potresti avere il vantaggio di maggiori<br>
personalizzazioni ma, considerando che costriuire GUI è _molto_<br>
ripetitivo, secondo me è meglio lasciarlo fare ad un apposito designer (sw).<br>
<br>
Iniziando ad usare un GUI builder ti accorgi subito che esso non fa<br>
altro che "scrivere codice ripetitivo" al posto tuo, sulla base di<br>
elementi che inserisci "visivamente" e parametrizzi. Molto comodo.<br>
Ovviamente ciò non basterà per la tua applicazione, perché vorrai fare<br>
altre cose (tipo richiamare metodi al verificarsi di eventi), ed a<br>
questo punto i vari GUI Builder, con 3 o 4 tecniche diverse (ma sempre<br>
stessa sostanza) ti consentiranno di aggiungere "tuo codice" al posto<br>
giusto. Questo è già molto comodo, ma dopo un po' ti accorgerai che<br>
rigenerare i files ogni volta diverrà scomodo, ed alle volte<br>
"pericoloso" (quando dovrai sovrascrivere i files vecchi, e rischierai<br>
di perdere pezzi di codice a causa di overwrite... a me è capitato...).<br>
<br>
A questo punto ci sono varie strade per evolvere, il mio primo passaggio<br>
è stato quello di utilizzare il GUI builder per generare solo le classi<br>
di descrizione della GUI, da cui derivare le mie classi che<br>
aggiungessero solo i metodi necessari (le risposte agli eventi di cui<br>
sopra). In tal modo, anche perdendo il sorgente generato dal GUI<br>
builder, non ci sono particolari problemi, basta rigenerarlo. Più<br>
sicuro, più elegante, più comodo...<br>
<br>
...ma non è detto che nemmeno questo ti soddisfi pienamente.<br>
Ci sono altre soluzioni più eleganti (ad esempio Glade per GTK, o xrc<br>
per wxWidgets aka wxPython) che generano "al volo" (a runtime) la GUI<br>
sulla base di un file di descrizione (normalmente in formato xml). In<br>
questo scenario il GUI builder non genera più codice, ma il file xml.<br>
<br>
Questa forse è la differenza di velocità di esecuzione di cui parli, il<br>
dover leggere a runtime un file xml da interpretare per creare la GUI<br>
richiede un po' di tempo di esecuzione in più rispetto ad una<br>
generazione "diretta" da codice.<br>
Tieni però presente che ciò è necessario solo in fase di costruzione<br>
della GUI, e non nel corso della successiva esecuzione (ci mette magari<br>
qualche istante in più a "disegnarsi" all'inizio, ma poi la velocità di<br>
esecuzione è la stessa con entrambe le tecniche).<br>
<br>
A questo punto sei tornata a scrivere "a mano" il codice, che però è di<br>
pochissime righe, tipo: "crea questo dialog sulla base di questa<br>
definizione trovata in questo file; visualizza" (ovvio che il<br>
virgolettato non è pseudocodice... :) ).<br>
<br>
Hai a questo punto il vantaggio di poter controllare tutto nei dettagli,<br>
mantenendo anche quello di "disegnare" esternamente la GUI. Hai codice<br>
"pulito" (beh, dipende da come lo scrivi...) ma hai anche un ulteriore<br>
vantaggio: se con un gui builder che produce "codice" sei legata a<br>
_quel_ GUI builder e quel linguaggio, passando a files di descrizione<br>
delle risorse puoi tranquillamente cambiare da un GUI builder<br>
(programma) all'altro (beh, più o meno...) ed _eventualmente_ da un<br>
linguaggio ad un altro (anche se, ovviamente, non si capisce perché<br>
dovresti passare da Python ad un qualsiasi altro linguaggio... ;) ).<br>
<br>
Ad esempio, alla fine del "giro" descritto io personalmente apprezzo<br>
Glade su GTK, e wxFormBuilder su wxWidgets/wxPython (oppure in<br>
alternativa anche wxGlade).<br>
<br>
Svantaggi veri dei GUI builder? Se hai da disegnare interfacce che per<br>
qualche motivo non riescono a gestire, o se devi usare widget non<br>
standard, in alcuni casi può diventare più complesso, ma nella<br>
stragrande maggioranza dei casi imho è più comodo.<br>
HTH<br>
<br>
my .02 Eur,<br>
max.<br>
<div><div></div><div class="h5">_______________________________________________<br>
Python mailing list<br>
<a href="mailto:Python@lists.python.it">Python@lists.python.it</a><br>
<a href="http://lists.python.it/mailman/listinfo/python" target="_blank">http://lists.python.it/mailman/listinfo/python</a><br>
</div></div></blockquote></div><br>