[Python] costruzione GUI

[danielita]

Innanzitutto grazie per le spiegazioni!

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?

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.
Ma ciò non è necessario nel corso della successiva esecuzione, perchè? Forse
perchè nella successiva esecuzione in entrambi i casi ho il bytecode?

Perdonami ma sono all'inizio con python e GUI....


Dany

Il giorno 28 marzo 2009 13.31, Massimo Masson <max a studiomasson.it> ha
scritto:

> danielita ha scritto:
> > Ok, è chiaro,
> > ma questo significa anche che:
> > realizzata la GUI con wxpython, quando l'utente finale utilizzerà la GUI
> > sarà tutto più veloce???
>
> [...]
>
> Secondo me, gli strumenti che usi per costruire la GUI non hanno
> influenza alcuna sulla velocità di esecuzione (a parità di altre
> condizioni), ma solamente sui tempi di scrittura del codice.
>
> Scrivere "a mano" è solo più tedioso che lasciarlo fare ad un programma
> apposito (GUI builder). "A mano" potresti avere il vantaggio di maggiori
> personalizzazioni ma, considerando che costriuire GUI è _molto_
> ripetitivo, secondo me è meglio lasciarlo fare ad un apposito designer
> (sw).
>
> Iniziando ad usare un GUI builder ti accorgi subito che esso non fa
> altro che "scrivere codice ripetitivo" al posto tuo, sulla base di
> elementi che inserisci "visivamente" e parametrizzi. Molto comodo.
> Ovviamente ciò non basterà per la tua applicazione, perché vorrai fare
> altre cose (tipo richiamare metodi al verificarsi di eventi), ed a
> questo punto i vari GUI Builder, con 3 o 4 tecniche diverse (ma sempre
> stessa sostanza) ti consentiranno di aggiungere "tuo codice" al posto
> giusto. Questo è già molto comodo, ma dopo un po' ti accorgerai che
> rigenerare i files ogni volta diverrà scomodo, ed alle volte
> "pericoloso"  (quando dovrai sovrascrivere i files vecchi, e rischierai
> di perdere pezzi di codice a causa di overwrite... a me è capitato...).
>
> A questo punto ci sono varie strade per evolvere, il mio primo passaggio
> è stato quello di utilizzare il GUI builder per generare solo le classi
> di descrizione della GUI, da cui derivare le mie classi che
> aggiungessero solo i metodi necessari (le risposte agli eventi di cui
> sopra). In tal modo, anche perdendo il sorgente generato dal GUI
> builder, non ci sono particolari problemi, basta rigenerarlo. Più
> sicuro, più elegante, più comodo...
>
> ...ma non è detto che nemmeno questo ti soddisfi pienamente.
> Ci sono altre soluzioni più eleganti (ad esempio Glade per GTK, o xrc
> per wxWidgets aka wxPython) che generano "al volo" (a runtime) la GUI
> sulla base di un file di descrizione (normalmente in formato xml). In
> questo scenario il GUI builder non genera più codice, ma il file xml.
>
> Questa forse è la differenza di velocità di esecuzione di cui parli, 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.
> Tieni però presente che ciò è necessario solo in fase di costruzione
> della GUI, e non nel corso della successiva esecuzione (ci mette magari
> qualche istante in più a "disegnarsi" all'inizio, ma poi la velocità di
> esecuzione è la stessa con entrambe le tecniche).
>
> A questo punto sei tornata a scrivere "a mano" il codice, che però è di
> pochissime righe, tipo: "crea questo dialog sulla base di questa
> definizione trovata in questo file; visualizza" (ovvio che il
> virgolettato non è pseudocodice... :) ).
>
> Hai a questo punto il vantaggio di poter controllare tutto nei dettagli,
> mantenendo anche quello di "disegnare" esternamente la GUI. Hai codice
> "pulito" (beh, dipende da come lo scrivi...) ma hai anche un ulteriore
> vantaggio: se con un gui builder che produce "codice" sei legata a
> _quel_ GUI builder e quel linguaggio, passando a files di descrizione
> delle risorse puoi tranquillamente cambiare da un GUI builder
> (programma) all'altro (beh, più o meno...) ed _eventualmente_ da un
> linguaggio ad un altro (anche se, ovviamente, non si capisce perché
> dovresti passare da Python ad un qualsiasi altro linguaggio... ;) ).
>
> Ad esempio, alla fine del "giro" descritto io personalmente apprezzo
> Glade su GTK, e wxFormBuilder su wxWidgets/wxPython (oppure in
> alternativa anche wxGlade).
>
> Svantaggi veri dei GUI builder? Se hai da disegnare interfacce che per
> qualche motivo non riescono a gestire, o se devi usare widget non
> standard, in alcuni casi può diventare più complesso, ma nella
> stragrande maggioranza dei casi imho è più comodo.
> HTH
>
> my .02 Eur,
> max.
> _______________________________________________
> Python mailing list
> Python a lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: http://lists.python.it/pipermail/python/attachments/20090401/7a4dd7d3/attachment.htm