Re: [Python] cambio al vertice
On Wed, 1 Apr 2009 11:31:18 +0200, Masci srad...@gmail.com wrote: Le motivazioni non fanno una grinza... http://www.python.org/dev/peps/pep-0401/ Notizione ogg! Fa il paio con questa: http://www.postgresql.org/community/weeklynews/pwn20090401 -- Daniele Varrazzo - Develer S.r.l. http://www.develer.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] costruzione GUI
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
Re: [Python] costruzione GUI
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
Re: [Python] costruzione GUI
concordo...io inizia al contrario e poi sono passato a farmi tutto a manina. Ora uso un approccio misto. -- Quiero ser el rayo de sol que cada día te despierta para hacerte respirar y vivir en me. Favola -Moda. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] cambio al vertice
Daniele Varrazzo ha scritto: On Wed, 1 Apr 2009 11:31:18 +0200, Masci srad...@gmail.com wrote: Le motivazioni non fanno una grinza... http://www.python.org/dev/peps/pep-0401/ Notizione ogg! Fa il paio con questa: http://www.postgresql.org/community/weeklynews/pwn20090401 Sapete in che data state scrivendo, vero? ^_^ max ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] costruzione GUI
danielita 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 ...scusa non ti sto seguendo molto... da quanto scrivo io tu deduci una cosa che hanno chiesto a te ??? Non mi quadra... 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? Beh, no... con il GUI builder costruisci i widget di interfaccia, uno dei quali sarà un canvas, all'interno del quale poi le cose le realizzerai programmandole tu... (il GUI builder disegna i componenti dell'interfaccia, e basta... il canvas è un widget, il gui builder si ferma li...). Peraltro, se le tue richieste riguardano oggetti (con maniglie, da ridimensionare, e via dicendo) da gestire via wxPython, ti suggerirei di guardare, nella demo standard, la sezione OGL (sotto miscellaneous mi pare...) 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? Probabilmente non sono stato chiaro, con costruzione della gui intendevo la creazione dei vari widget da parte del programma (in esecuzione), non il tempo di design da parte del programmatore... Il concetto è che nel caso si usi un file di risorse che descrive la GUI il programma, per disegnare la stessa, deve leggere un file di testo che descrive la GUI, e sulla base di quella descrizione generare i widget. Se il tutto è codificato (ovvero già scritto nel codice) in esecuzione si può procedere a generare i widgets senza leggere la descrizione dal file di testo. Questa è la differenza(1). Poi le GUI generate, a parità di widget usati, si comportano nello stesso identico modo. Ovviamente la lettura del file di configurazione verrà effettuata ad ogni esecuzione. HTH, max. (1) questa differenza di esecuzione è piccola con Python, ma può diventare più significativa con linguaggi compilati, tipo C++, che non devono interpretare il sorgente (o p.code). Peraltro, nei linguaggi compilati consente l'innegabile vantaggio di poter rifare la gui senza dover ricompilare il sorgente. In Python te ne accorgi meno perchè potresti facilmente modificare il codice, ma se fossi in ambienti dove il sorgente va protetto la strada dei files di risorse diventa estremamente importante. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] costruzione GUI
On Wed, 1 Apr 2009 15:43:15 +0200, salvatore monaco salvatore.mon...@gmail.com wrote: 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. +1 Penso che i GUI builder siano strumenti che semplificano un lavoro tedioso, ma che sia fondamentale capire quello che fanno, perché non fanno altro che creare una descrizione di una sequenza di operazioni. Quando qualcosa comincia ad andare male è necessario avere un minimo di dimestichezza con le operazioni che si intendevano svolgere, altrimenti il debug diventa impossibile. Il fatto che non sia questo che ha insegnato il Visual Basic è un discorso diverso: quella è una scelta di design ormai considerata fondamentalmente sbagliata e di cui non è il caso ripercorrere gli errori. Tra l'altro, in WX (come in QT e immagino altrove) esistono i Sizer che consentono di non dover specificare in maniera assoluta il posizionamento dei widget, ma solo in maniera relativa, per cui descrivere a codice un'interfaccia non è un'operazione che richiede il disegno sulla carta millimetrata. -- Daniele Varrazzo - Develer S.r.l. http://www.develer.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
