[Python] costruzione GUI

Mer 1 Apr 2009 15:43:15 CEST

Ciao Daniela
ti do un parere perche' ho avuto lo stesso problema
come con le wxPython  anche in java con le swing

l'approccio GuiBuilder e' ovviamente molto intuitivo e veloce
ma se e' la tua prima esperienza con queste tecnologie ti consiglio di
cominciare a manina prima di far fare i mestieri all' IDE RAD
cosi' capirai piu' a fondo il contesto e sopratutto imparerai dai tuoi
errori
quando avrai masterizzato (to master) le wx potrai passare ad un gui builder
comprendendo meglio quello che gli chiedi di fare al tuo posto e sapendo
intervenire senza esitazione nel momento gisto e al posto giusto.

questa la mia esperienza....

Il giorno 1 aprile 2009 13.16, danielita <danielita74 a gmail.com> ha scritto:

> 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
>>
>
>
> _______________________________________________
> 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/b2fa0a57/attachment.htm 