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 <danielit...@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 <m...@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@lists.python.it >> http://lists.python.it/mailman/listinfo/python >> > > > _______________________________________________ > Python mailing list > Python@lists.python.it > http://lists.python.it/mailman/listinfo/python > >
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python