[Lugge] Re: Rif: Re: esportazione da Glade a Windows
- From: Roberto A.Foglietta <fogliettar@xxxxxxxxxxxxxxxxxx>
- To: lugge@xxxxxxxxx
- Date: Fri, 20 Sep 2002 16:39:25 +0200
On Fri, 20 Sep 2002 16:40:36 +0200
ianezz@xxxxxxxxxx wrote:
> Il clone di giuse.massa@xxxxxxxxxxxx ha segretamente scritto:
>
> > quali tools di cross-compiling mi consigliate allora? Esiste
> > qualche consiglio, tipo manuali in rete che affrontino l'argomento?
>
> Dopo qualche anno di sviluppo di GUI sono arrivato alla conclusione
> *del tutto personale* che sviluppare GUI cross-piattaforma
> *interamente* in C/C++/Java e` in moltissimi casi solo una gran
> perdita di tempo, e che per queste cose son decisamente piu` adatti
> ambienti tipo Perl/Python/Tcl con toolkit tipo Tk o wxWindows, e
> usando il C/C++ solo per le parti ove questo e` opportuno.
>
> Chiaro, non e` certo cosi` per TUTTI i casi.
>
A parte casi particolari in cui e` richiesto che il programma si interfacci ad
HW, magari dedicato, e/o sia staticamente compilato includendo dal livello
quasi-driver al livello di lib astratta di manipolazione oggetto generico i
linguaggi script oriented creano piu` problemi di quanto ne risolvano.
L'unica cosa che si puo` dire e` che convenga fare un programma che funga da
linea di comando ed eventualmente accetti I/O mediante shared memory e poi
usare l'interfaccia grafica piu` conveniente per la piattaforma che si sta
usando.
Separa codice da funzionale da codice I/O e` molto importante, tanto che alla
fine sui miei sistemi embedded ormai si trovano programmi che comunicano per
shared-memory in locale e socket in remoto (qualora desideri esportarli) con
vari livelli:
- accesso HW dedicato (driver) in kernel space
- lib di accesso I/O<->HW con chiamate omogenee su diversi HW di I/O (server
in shared memory)
- programma di controllo/elaborazioni I/O (con collegament shared memory verso
il basso agli I/O e come server INFO per il visualizzatore)
- visualizzatore (parsing di .INI => renderizzazione oggetti con agg dinamico
verso INFO mediante shared memory)
s/shared memory/socket/g quando voglio remotare
Dopo essermi sbattuto come un orco per remotare il display dell'embedded
(framebuffer) su un windows (gtk+) sono giunto alla conclusione che facevo
prima prendere le librerie che mi servivano compilarmele in modo da ridurre lo
spazio e fare in modo che host e embbeded siano in grado di far girare i
medesimi applicativi.
IMHO il cross o porting delle GUI e` qualcosa che dovrebbe essere evitato,
cioe` evitare di farlo insieme al codice 'funzionale'.
Ma perche` una cosa del genere risulti una liberazione invece che una condanna
per altri inferni devi saper programmare un poco meglio del programmatore
medio, cioe` devi avere quell'esperienza che ti ha affinato il buon senso da
sapere quali strade tentare, quali abbandonare a priori e sopratutto +/- come
impostare il lavoro perche` esso non ti sommerga divorandoti tutto il tempo.
Ciao,
--
,__ ,_ ,___ .-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-.
||_) ||\ ||_ / GEA Automotive S.R.L. |
|| \ ||¯\ ||¯ Software Research & Development Division |
¯¯ ¯° ¯¯ ¯° ¯¯ ° tel.: +39 010 65966917 |
Roberto A. Foglietta com.: mailto:fogliettar@xxxxxxxxxxxxxxxxxx |
\ Linux & SW Architect per.: http://digilander.iol.it/robang |
`-----------------------=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-'
========----------
Prima di scrivere in m-list per favore leggi il regolamento
http://www.lugge.net/soci/manifesto.htm#list
Archivio delle e-mail postate in lista
//www.freelists.org/archives/lugge/
Modifica dell'account su freelists
//www.freelists.org/cgi-bin/lsg2.cgi
----------========
La sede e` aperta ogni martedi` pomeriggio 14.30-18.00
http://www.lugge.net/soci/sede.htm
Other related posts:
