Newsgroup: it.comp.os.linux.development
Titolo: Problema GTK: CLIST

Ciao a tutti, ho un problemino con l'inserimento di riche in una clist.
Premetto che l'interfaccia č realizzata tramite glade...
Allora, per passare i testi da inserire nelle colonne di una riga di una
clist, utilizzo:
char nomevariabile[n_colonne][n_caratteri]
Quando aggiungo la riga:
gtk_clist_append(CTK_CLIST(clist),nomevariabile)
(prototipo: int gtk_clist_append(GtkClist *clist, char *vettore[]);)
mi da segmentation fault.
Se invece utilizzo:
char *nomevariabile[n_colonne]
e alloco n_caratteri per ciascuna colonna tramite calloc,
l'inserimento di una riga nella clist funziona senza problemi.
Sicuramente č un problema di gestione puntatori/vettori, piu' che di
gtk...potete darmi una mano???
--------------------------------
Inviato via 
http://usenet.libero.it

 char nomevariabile[n_colonne][n_caratteri]
 > gtk_clist_append(CTK_CLIST(clist),nomevariabile)
 > mi da segmentation fault.
Il problema non sta sicuramente qui, ma probabilmente dove riempi questo 
array!
Bye,
  Gabry

 char nomevariabile[n_colonne][n_caratteri]
Non farlo, a prescindere. È come urlare: "voglio un buffer overflow, e
lo voglio adesso".
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)           [ 
http://digilander.libero.it/ebassi/
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 lo voglio adesso".
la clist mi serve solo in outout: gestisco e controllo io il testo
inserito...
Grazie comunque per i suggerimenti...
Cippa Lippa
P.S.: é oneroso passare da gtk 1.2 a 2.0???


 Riformulo: perché usi le GTK 1.2 che sono deprecated?
Ti posso spiegare perche' le uso io:
- Una GtkCList e' piu' veloce di qualunque altro modello di lista 
presente in gtk 2.0
- Un GtkTree e' piu' veloce di qualunque albero ottenibile con
gtk 2.0.
- Le GTK 1.2.x sono altamente stabili, su ogni architettura, la serie 
2.0.x presente di serie nelle distribuzioni moderne e' buggatissima,
la serie 2.2.x in pratica non la distribuisce ancora nessuno...
- La documentazione delle gtk 2 e' scarsa, e di cartaceo non c'e' nulla, 
anche la documentazione delle gtk 1.2 non e' un granche', ma almeno ci 
sono libri (in ufficio abbiamo Programming GTK+ in C, che non e' 
malaccio) e soprattutto ci sono decine di applicazioni di uso comune (da 
sylpheed a lopster per esempio) che danno ottimi esempi di come 
sfruttare le librerie al limite.
- Nella debian woody ci sono quelle come standard, ed e' la 
distribuzione di riferimento per i nostri clienti.
- Sinceramente non mi piace come sono state costruite le gtk2, per la 
compatibilita' unicode hanno sacrificato DRAMMATICAMENTE la velocita' e 
le prestazioni. Gli strati intermedi che hanno aggiunto (pango ad 
esempio) sono pesanti anche come risorse consumate. Le nuove api per 
liste ed alberi sono incredibilmente macchinose e farraginose, gia' si 
parla nelle mailing list di gtk di una possibile riscrittura (almeno dei 
meccanismi interni) per gtk 2.4... Penso che, se per la prossima 
applicazione avro` un sufficiente timeframe per qualche sperimentazione, 
che provero` a scriverla con wxWindows...
Bye,
  Gabry


[CUT]
Mi sa che non passero' tanto facilmente alle 2.x...almeno a sentire i tuoi
commenti..!


 P.S.: é oneroso passare da gtk 1.2 a 2.0???
Essenzialmente, in termini di mero porting, no. A parte CList, CTree e
Text, non è cambiato poi molto, tra un major version e l'altro.
Se, invece, si usano i widget di cui sopra, il passaggio è delicato.
Si è passati da una serie di widget a un meccanismo MVC
(Model/View/Controller), e ad una unificazione tra alberi e liste (le
seconde come caso particolare dei primi). In pratica, tutte le modifiche
vengono fatte su modelli (TreeStore, ListStore o qualsiasi oggetto che
eredita da TreeModel, per quanto riguarda alberi/liste, e TextBuffer per
quanto riguarda il testo); le modifiche si rifletteranno sui widget che
controllano quei modelli, ovvero TreeView e TextView.
C'è poi il passaggio alle stringhe Unicode, necessario dato che, ormai,
tutte le interfaccie grafiche che vogliono essere
localizzabili/internazionalizzabili devono supportarle (non esiste solo
l'occidente).
In più, c'è una più precisa separazione tra i vari componenti: Glib,
GTK, GDK, Pango e ATK (ciò permette anche un migliore processo di
scrittura di binding per altri linguaggi oltre il C; vedi PyGTK e
gtk2-perl).
+++
I lati negativi? L'MVC è più lento di un approccio "diretto" (anche se,
dal punto di vista di manutenibilità, paga meglio), la documentazione,
specie per le parti più "esoteriche" non è tantissima (ma si sta
muobendo qualcosa, specie per quanto riguarda il sistema di
programmazione object oriented in C messo a disposizione dalle Glib), e
il supporto per l'Unicode rende il rendering dei font più lento (ma,
come ho detto, non si poteva fare a meno del supporto Unicode).
+++
Perché effettuare il passaggio? Perché le GTK 2.x sono mantenute e le
1.2 no. Perché se si deve scrivere un nuovo software, è meglio fare il
porting ora, piuttosto che aspettare, e vedere il divario tecnico
allargarsi. Perché, ad ogni buon conto, se usi le GTK 1.2 e ti capita
qualcosa, non saprai mai se è un errore delle librerie oppure della tua
applicazione; e anche nel caso in cui fosse un errore delle librerie,
non sarebbe corretto, dato che non sono mantenute.
Ergo: se stai scrivendo una nuova applicazione, e hai la possibilità,
usa le GTK 2. Le distribuzioni nuove (Red Hat 9, Mandrake 9, Debian
Sarge, e penso anche SuSE) le portano aggiornate.
