Innanzitutto grazie per le spiegazioni!<br><br>Da quanto hai scritto deduco che evidentemente mi hanno chiesto di sviluppare la GUI a &quot;manina&quot; (usando wxpython) perchè devo aggiungere al frame un canvas in cui inserire oggetti (immagini, testo) su cui realizzare a &quot;manina&quot; 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&#39; di tempo di esecuzione in più rispetto ad una generazione &quot;diretta&quot; 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&#39;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">&lt;<a href="mailto:max@studiomasson.it">max@studiomasson.it</a>&gt;</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">&gt; Ok, è chiaro,<br>
&gt; ma questo significa anche che:<br>
&gt; realizzata la GUI con wxpython, quando l&#39;utente finale utilizzerà la GUI<br>
&gt; 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 &quot;a mano&quot; è solo più tedioso che lasciarlo fare ad un programma<br>
apposito (GUI builder). &quot;A mano&quot; 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 &quot;scrivere codice ripetitivo&quot; al posto tuo, sulla base di<br>
elementi che inserisci &quot;visivamente&quot; 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 &quot;tuo codice&quot; al posto<br>
giusto. Questo è già molto comodo, ma dopo un po&#39; ti accorgerai che<br>
rigenerare i files ogni volta diverrà scomodo, ed alle volte<br>
&quot;pericoloso&quot;  (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 &quot;al volo&quot; (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&#39; di tempo di esecuzione in più rispetto ad una<br>
generazione &quot;diretta&quot; 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 &quot;disegnarsi&quot; all&#39;inizio, ma poi la velocità di<br>
esecuzione è la stessa con entrambe le tecniche).<br>
<br>
A questo punto sei tornata a scrivere &quot;a mano&quot; il codice, che però è di<br>
pochissime righe, tipo: &quot;crea questo dialog sulla base di questa<br>
definizione trovata in questo file; visualizza&quot; (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 &quot;disegnare&quot; esternamente la GUI. Hai codice<br>
&quot;pulito&quot; (beh, dipende da come lo scrivi...) ma hai anche un ulteriore<br>
vantaggio: se con un gui builder che produce &quot;codice&quot; 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&#39;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 &quot;giro&quot; 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>