[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
 http://www.freelists.org/archives/lugge/

 Modifica dell'account su freelists
 http://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: