Newsgroup: it.comp.os.linux.development
Titolo: Finestre multiple con pygtk.

Sto iniziando il lavoro di porting del mio newsreader su GTK2. Il 
newsreader  scritto in python e per l'interfaccia uso Glade. Al momento 
utilizzo un unico file .glade in cui ci sono tutte le finestre che 
compongono il programma, inizialmente quelle che non devono essere 
visibili sono hide e poi le mostro quando mi servono.
In occasione del passaggio verso GTK2 volevo sperimentare qualche 
soluzione piu' flessibile.
Mi chiedevo quale sia l'organizzazione migliore, io ad esempio stavo 
valutando l'idea di creare un file .glade diverso per ogni finestra, e 
di creare anche un .py diverso per ogni finestra, in questi moduli 
implementerei la classe che contiene tutte le callback per la finestra.
La struttura del programma prevede una finestra principale, due finestre
che devono essere aperte su richiesta e poi un fontselectiondialog ed un
colorselection dialog.
Secondo voi qual'e' la soluzione migliore?
-- 
 |\ |       |HomePage   : 
http://digilander.libero.it/nemesis2001/
 | \|emesis |XPN (my nr): 
http://xpn.altervista.org

 Secondo voi qual'e' la soluzione migliore?
Come ho detto, le due dialog box possono essere create come classi
separate e costruite "in code". Esamina la funzione delle due finestre
che devono essere aperte su richiesta, e la frequenza con cui esse
devono essere aperte dall'utente, e vedi se, per caso, possono essere
messe in una tabbed window, oppure ridotte fino ad essere realizzate "in
code" e non disegnandole attraverso Glade.
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)       [ 
http://digilander.libero.it/ebassi/blog
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

code" e non disegnandole attraverso Glade.
Questa in effetti e' un'idea, il codice per creare le dialog box 
dovrebbe essere molto semplice.
Cmq la scelta di usare file .glade diversi per le diverse finestre 
(anche dettata dal fatto che per la finestra principale vorrei 
realizzare 3 layout diversi) ti sembra buona?


 questa.
Quel problema esiste ancora.
E' una cosa del tipo
chiamo funz:
 1)carico il widget da libglade
 2)lo uso
chiamo funz:
 1)mi spiallo chiamando il widget :) o meglio ritorno None
Non so bene come funzioni, ma e' fastidioso.
Per un progetto anch'io ho risolto mettendo un'altra grossa finestra in un
file a parte.
Attualmente uso file glade diversi per finestre molto complesse.
Dialogs et similia li scrivo a mano.
Ho cercato proprio ieri se qualcuno era andato avanti con i progetti stile
'glade2py', ma purtroppo non vengono aggiornati alle versioni recenti di
glade. moan...
Chissa', forse quando avro' finito il mio prog ci pensero' io
Ciao,
Riccardo
-- 
-=Riccardo Galli=-
 _,e.
s~  ``
 ~@.   ideralis Programs
.   ol 
 `**~  
http://www.sideralis.net

 realizzare 3 layout diversi) ti sembra buona?
Si, dato che molti progetti comunque usano Glade per il disegno delle
UI. Personalmente, non mi è mai piaciuto, dato che non ho mai disegnato
applicazioni così complicate da richiedere il disegno di UI per renderla
sana.
Quanto al caricamento, come ho scritto, tenta di dedurre la frequenza
con cui devono essere aperte le varie finestre, e di caricare l'XML di
una finestra solo quando richiesta. A quel punto, se sai che l'utente
vorrà ricaricarla a breve, tienila "in caldo", magari con un meccanismo
di timeout che la rimuova dalla memoria se superato un determinato
intervallo.


  1)mi spiallo chiamando il widget :) o meglio ritorno None
Probabilmente perche' non fai un return gtk.TRUE alla fine della callback
che hidda la finestra. In questo modo il widget viene distrutto e alla
seconda chiamata non ce l'hai piu'.
Bye.

 Bye.
Controllero', grazie
Riccardo

Chissa', forse quando avro' finito il mio prog ci pensero' io
Ecco questa sarebbe una cosa interessante. Mi pare ci sia solo il 
vecchio glc (o come cacchiarola si chiamava), ma funzionava solo per 
gtk1.2 e non era molto avanzato. Pero' a me piacerebbe molto un tool del
genere, inoltre ti permetterebbe anche di imparare velocemente a 
programmare direttamente con le primitive di gtk.
P.S. Al volo, ho notato che i tooltips che ho impostato per i pulsanti 
di una toolbar non vengono visualizzati quando il programma gira (mentre
si vedono nell'anteprima della finestra che ti fornisce Glade), e' un 
problema mio oppure e' un bug noto? 
Sui pulsanti normali si vedono correttamente.


intervallo.
Questo non penso sia un problema. Le due finestre sono rispettivamente 
quella per la sottoscrizione dei newsgroup e quella per la 
configurazione del programma. In condizioni normali vengono richiamate 
molto raramente.
Cmq hai stuzzicato la mia curiosita', una provetta di scrivere 
l'interfaccia direttamente con pygtk penso di farla :-)


 molto raramente.
La butto lì, magari è una stronzata...
Invece di usare una finestra per la sottoscrizione dei newsgroup, perché
non usare un druid? Quelli si costruiscono in 10 minuti, senza usare
Glade, e aiutano moltissimo nella razionalizzazione dell'UI (anche se
non sono amati dai poweruser).


non sono amati dai poweruser).
Mah ti diro' gia i druid non mi piacciono molto, e poi non mi pare sia 
molto adatto alla sostizione della finestra per la sottoscrizione. 
Potrebbe essere una buona idea per sostituire la finestra di 
configurazione, almeno per la configurazione iniziale ...


 perche'?
Approfitto anch'io che, contento programmatore Perl, vedo sempre più
spesso thread su Python. So che il Perl non è forse il linguaggio +
indicato per fare cose complesse, ma ha tante altre potenzialità
straordinarie, imho.
Mi piacerebbe sapere le motivazioni che spingono verso l'uno o l'altro
linguaggio.
Ciao
-- 
+--------+ ASCII ribbon campaign ( )
|  kral  |  - against HTML email  X 
+--------+              & vCards / \

 perche'?
Questo meriterebbe un thread a parte. :-)
Ad ogni modo, l'approccio delle Gtk2 in Perl è più "piegare le librerire
allo stile del linguaggio", invece di un semplice mapping 1:1 come
avviene in Python. Ad esempio: ove possibile, in gtk2-perl si tenta di
passsare strutture dati Python, invece di instanziare classi; questo
aumenta la consistenza del linguaggio, e dio solo sa se ce n'è bisogno
in Perl... ;-))))
Seriamente: ritengo il Perl indicato per la prototipazione, e per il
design top-down dei progetti; è sporco, è cattivo e ti porta a
destinazione molto più velocemente di altri linguaggi. Però, alla fine,
è come con la macchina dei Blues Brothers, che va in pezzi alla fine del
film dopo averne passate di tutti i colori. :-) Con il Python c'è un
approccio più razionale, più bottom-up. Il design di un'applicazione la
fa da padrone.
Sono due linguaggi differenti, con due scope che solo parzialmente
coincidono. Poi, va beh, io ho un debole per il Perl. :-)


coincidono. Poi, va beh, io ho un debole per il Perl. :-)
Descrizione semplice ed esauriente :-D
