Newsgroup: it.comp.os.linux.development
Titolo: Dubbio GTKTreeView

Sto giochicchiano un po' con il nuovo TreeView. Mi chiedevo, ma e' 
possibile che non sia possibile cambiare la forma dell'expnander 
tornando al classico quadratino con il + o il - all'interno? e non 
e' nemmeno possibile visualizzare la riga tratteggiata che unisce il 
padre al figlio??
A questo punto quasi quasi ritorno al vecchio CTree, ho pero' un timore,
visto che ormai questo widget e' deprecated non e' che nelle prossime 
versioni di GTK lo toglieranno?
-- 
 |\ |       |HomePage   : 
http://nem01.altervista.org
 | \|emesis |XPN (my nr): 
http://xpn.altervista.org

 versioni di GTK lo toglieranno?
Infatti lo toglieranno. Possibilmente, prima della prossima major
revision (3.0), anche se penso che aspetteranno la prima release che non
sia più ABI-compatibile.
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)       [ 
http://digilander.libero.it/ebassi/blog
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 versioni di GTK lo toglieranno?
Probabilmente si, nella ML Owen Tayor non fa altro che dire di non usare 
GTK 1.x e i widget deprecated :), nella 2.2 tra l'altro per averli 
bisogna compilare con -DENABLE_DEPRECATED...
Al momento mi sto guardando GTK 2 nello spare time tra una segnalazione 
gnats e l'altra della GROSSA applicazione (circa 30 finestre, drag&drop, 
menu' contestuali...) sviluppata con GTK 1.x nei mesi passati.
Beh, dalle analisi che ho fatto sui principali cambiamaneti 
(TreeView/Model, TextView/Buffer... rispetto ai vecchi widget) 
l'impressione che ho avuto e' che queste nuove astrazioni abbiano reso 
il sistema troppo object oriented per essere programmato agevolmente in C.
Bye,
  Gabry

 il widget. :-)
La cosa giusta da fare e' un gtk_widget_get_style(), modificare lo stile 
a piacimento e poi fare un set_style().
Sinceramente non ci vedo nulla di male, ci sono numerosi casi in cui lo 
sviluppatore DEVE modificare quello che l'utente a deciso.
Pensa ad un terminale ANSI per esempio, DEVE avere lo sfondo nero anche 
se l'utente ha settato per il background del GtkTextView di default una 
bella texture gialla a pallini viola :)
Bye,
  Gabry

 bella texture gialla a pallini viola :)
Perché *deve*? I terminali ANSI potrebbero essere black on white, green
on black, grey on black, white on blue, etc... ;-)


 il sistema troppo object oriented per essere programmato agevolmente in C.
Per questo esistono i binding in linguaggi superiori.
Ormai, buona parte dei binding usa tool automatizzati per creare i
wrapper intorno alle librerie in C (più per mantenere la sanità mentale
di chi crea il binding che per altro), ergo si può sempre scrivere una
parte performance-critical in C e poi realizzarne in binding in un
linguaggio come Perl e Python.
Ovviamente, se ci si può permettere l'overhead aggiunto, che non è così
grande come si pensa, anzi; in gtk2-perl è sicuramente più pesante
portarsi dietro l'interprete Perl che non il round trip time del
percorso perl -> librerie -> perl. Stesso dicasi di PyGTK.


sia più ABI-compatibile.
Ma porca ..... :-/


a piacimento e poi fare un set_style().
Un momento! con il get_style()/set_style() io come faccio ad introdurre 
le righe tratteggiate modificando lo stile?


il sistema troppo object oriented per essere programmato agevolmente in C.
A beh, ma io uso Python ;-)


 on black, grey on black, white on blue, etc... ;-)
Io parlavo di terminale ANSI atto a visualizzare cose tipo ANSI art o 
BBS, in quei casi c'e' una convenzione di background nero e 8 colori a 
tinta intensa piu' altri 8 a mezza luminosita', ovvio che l'utente possa 
configurarli se vuole vedere un albero di natale violetto nessuno puo' 
dirgli di no, ma sono cose che secondo me e' meglio fare tramite un 
pannello di configurazione dell'applicazione, NON tramite un file RC al 
quale l'utente occasionale non sarebbe mai in grado di mettere mano!
Bye,
  Gabry

 Ma porca ..... :-/
Già adesso ci vuole un'opzione apposta per compilarlo, se non ricordo
male.


Oppure, modifichi le proprietà del widget (sono nelle API).
Qua non ti seguo, se magari potessi fare qualche esempio.


 Ti riferisci al get_style()/set_style()?
No, a parse_rc_file(). set_/get_style() servono per le modifiche
in-code allo stile.


'ENABLE_DEPRECATED_WIDGETS'.
Bah, cmq le gtk di RH9 sono compilate in questo modo visto che Glade mi 
permette di inserire tranquillamente i widget deprecated ...


 permette di inserire tranquillamente i widget deprecated ...
Il che potrebbe essere un problema nel trasferimento ad altre distro che
non usano il flag, o su cui gli utenti si rollano le loro release (e.g.
Gentoo/Slackware); ecco perché usare un widget deprecato può essere fonte
di immensi mal di testa. ;-))


di immensi mal di testa. ;-))
Ma infatti non ho intenzione di usare widget deprecated, pero' insomma 
il fatto che su RH9 siano compilate cosi' (e sospetto che lo siano anche
su altre distro) e il fatto che Pan usi il CTree (non ne sono certo ma 
penso proprio sia cosi', appena ho tempo cerco di dare uno sguardo ai 
sorgenti) mi pare un segnale.


sorgenti) 
Ok ora ne sono certo. Pan 0.14.2
----file articlelist.c------------------riga 2299
Pan.article_ctree = w = gtk_ctree_new_with_titles 
(articlelist_column_qty,i,titles);
-------------------------------------------------
Certo che e' una scelta coraggiosa ... o incosciente.


 potrebbe senz'altro fare questo sporco lavoro ... e non sono io :-D
LOL... Al momento non ho proprio tempo, ma ho idea che, per implementare
Gtk2::SimpleList in C nativo, invece che in Perl, ci perderei metà della
vita. :-)


vita. :-)
Ma pensa che vita interessante sarebbe :-D
