aZaZel wrote: > > >>>>> "Guido" =3D=3D Guido Brugnara <gdo@xxxxxxxxx> writes: > Guido> Ma se il Plug-In occupa il 100% dello spazio > Guido> (visibile e temporale) che senso ha scomodare la prima > Guido> applicazione? (per la verit=E0 i Plug-In non gestiscono le > Guido> connessioni HTTP) > > Boh, anche la tua per quanto riguarda il dhtml e' una pia illusione > anche nel tuo caso si tratta comunque di pagine che non potranno > essere consultate con browser per cui non hai previsto > compatibilita'... alla fin fine il problema si riduce sempre a mettere > l'utente nelle condizioni di interagire col sito scomodandolo il meno > possibile e facendolo lavorare con quello che ha..e mi sembra che con > ie 5.5 il flash plugin venga installato di fisso. Si IE5.5 si ma non per gli altri browser e quindi non puoi farci affidamento. In quanto la 'pia illusione' sono concorde con Te; stiamo assistendo ad un graduale aumento della complessità dei browser con un stillicidio di nuovi protocolli più o meno standard di formati ancor meno standard ma soprattutto di prodotti (sia commeciali che GPL o free) ancor meno coerenti con gli standard. Per ora ci si salva utilizzando un minimo comun denominatore che ti permette di generare delle pagine statiche anche belline esteticamente. Per andare oltre le mie esperienze si sono ridotte a garantire la compatibilità verso un unico browser di quella precisa versione (intendo versione esatta senza pensare di usare versioni intermedie), ma in quei casi si tratta di applicazioni Intranet, anche se in rete geografica. > > >> Ho dato un'okkio alla tecnologia flash, di cui ora esistono > >> delle engines open source per la creazione dinamica scriptabili > >> in python (zope e non), perl, ruby, php ecc. (per esempio > >> http://www.opaque.net/ming). Il formato degli stream flash =3DE8 > >> stato pubblicato da macromedia nel 1998 e devo dire che quello > >> che si pu=3DF2 fare =3DE8 ormai veramente notevole... al di l=3DE0 > >> del solito filmato flash con annessi e connessi le ultime > >> release presentano notevoli miglioramenti anche riguardo alla > > Guido> A parte lo sfogo comunque le form HTML, accoppiate all'uso > Guido> di CSS permettono ora la realizzazione di GUI molto > Guido> sofisticate (attenzione, in questo caso le animazioni tipo > Guido> 'vi sorprenderemo con meravigliosi effetti speciali' non si > Guido> utilizzano). La compatibilit=E0 tra i browser si =E8 ridotta, > Guido> ma solo perch=E8 sono aumentate le possibilita per cui ci=F2 > Guido> che =E8 in comune =E8 ora sufficiente. > > Mah resto perplesso, non ho mai visto forms html cos=EC complesse come > lo sono gui normali....c'=E8 un deficit notevole dal punto di vista > dell'usabilit=E0 ...guarda la select html, non sar=E0 mica un combo > decente... Anche creare una window modale =E8 un reale problema per chi > fa "cross-browsing"... Il fattore di compessità era riferito a form html tradizionali, non alle form generate per una applicazione grafica tradizionale! quindi hai ragione a dire che una GIU grafica nativa (Gtk, Qt, Wmf, Tk ecc.) permette una maggiore complessità ma soprattutto interattività. > > E' chiaro che anche in tutti gli ambienti deve essere fatta la "colla" > di gestione di queste forms, ma l'idea che ho =E8 che con gli strumenti > html si parta svantaggiati. > > Guido> A questo punto penso che soluzioni con l'utilizzo di > Guido> Tcl/Tk, Pyton/Tk o Perl/Tk siano alla fine dei conti pi=F9 > Guido> realistiche, pi=F9 performati e molto meno avide di risorse, > Guido> 'girano' senza problemi su pi=F9 piattaforme da alcuni anni; > Guido> quindi sono anche stabili e la documentazione =E8 corposa. > > Aggiungerei python/wxwindows...=20 Si, scusa; ho visto che il RAD commerciale per wxWindows supporta ora anche il Perl e allora potrebbe essere interessante anche per il sottoscritto; non è che sia contrario a Pyton ma come sai bene sto cercando di costituire un gruppo omogeneo e l'attuale minimo comune denominatore è attualmente il Perl. > > Guido> Piccolo ma non trascurabile difetto: sono evitate dalle > Guido> Aziende in quanto non permettevano di realizzare codice > Guido> eseguibile (non =E8 pi=F9 cos=EC, sia per Tcl che per il Perl; > Guido> non so per Pyton); sono evitate dalla Comunit=E0 Internet > Guido> perch=E8 non sono all'ultimo grido; appena parlo di Tk mi > Guido> dicono che =E8 vecchio, che non supporta i Thread che =E8 > Guido> meglio Gtk, che =E8 Meglio Qt ecc; ma non vedo molti > Guido> programmi (che non siano una montagna di codice C o C++ con > Guido> migliaia di ore di sviluppo) che siano disponibili per > Guido> Windows, Mac ed i vari Unix, Linux e BSD. > > Scusa??? cosa importa quello che la fantomatica comunit=E0 internet > pensa di una tecnologia se questa fa al caso tuo? Rischio che quella soluzione si areni e non abbia continuità (oddio anche la continua trasformazione porta allo stesso risultatao) e che ciò che produco non abbia Mercato. > e poi, se la vuoi > mettere su questo piano, anche html+javscript + tutto il resto > dell'ambaradam non =E8 pi=F9 considerato all'ultimo grido, vedi cose come > appunto sash, entity (www.entity.cx) ed anche il pur giovane BlueBox > (www.dloo.org) che propone un diverso approccio al problema, il PyUIML > Renderer ..una bella idea (pyuiml.sourceforge.net) > > * Snarfzilla: a GUI for Freenet. http://snarfzilla.sourceforge.net/ > > * Boa-Constructor: RAD GUI Building IDE for wxPython http://boa-constructor= > .sf.net > > mah...almeno alcune di quelle ne ho viste, applicazioni cross-browser > in dhtml abbastanza complesse invece... Una ad esempio l'hai nominata: sash Ho raccolto le varie informazioni nella tabella: prodotto linux Win stato Lic. tecnologia e linguaggi ---------------------------------------------------------------------- sash SI beta? free XML HTML Javascript sashXB SI early stage LGPL Gnome Gecko XML HTML Javascript (un confronto tra sash e sashXB http://news.gnome.org/gnome-news/966964532/967038378/967103522/index_html) Qt SI SI stable GPL o commerciale C++ e vari script Gtk SI si stable LGPL (ancora beta per windows) wxWindows SI SI stable LGPL vari script e vari RAD Tk SI SI stable art. vari script RAD minimale PyUIML SI ? pre-Alpha LGPL XML wxPyton HTML BlueBox SI SI alpha GPL KDE GNOME Entity SI SI beta? MIT Gtk XML e vari script (nota: la versione di Entity per Windows richiede la compilazione con CYGWIN e non mi pare disponibile gia compilata; o sbaglio?) In conclusione mi pare che le nuove soluzioni siano ancora lontane dalla maturità (maturità per un utilizzo Cross-platform); verifico con maggior dettaglio soluzioni con l'uso di wxWindows e abbandono almeno per ora l'idea del Cross-Browsing ... alla prossima Guido Brugnara > > >> il javascript di flash =3DE8 il medesimo su tutte le piattaforme > >> che flash supporta. Naturalmente ha anche le sue > >> pecche...fidarsi di uno standard comunque proprietario =3DE8 da > >> valutare... ed =3DE8 da valutare anche il fatto che con un > >> browser non supportato proprio non si vede una mazza di una > >> pagina che utilizza massivamente flash...ma del resto, anche > >> con dhtml se usi lynx o links hai ben poche speranze.... > > Guido> Se lynx e lincs non implementano HTML4.0, DOM, e JavaScript > Guido> le speranze resteranno vane in eterno! > > che versione di dom, che versione di javascript, la verit=E0 delle > librerie javascript cross platform =E8 che nei punti cruciali c'=E8 sempre > un bel case che discerne tra le varie versioni del browser... i > browser possono avere tutto il supporto di questo mondo, ma devono > comunque essere contemplati dalla libreria sul server, per > essere compatibili.... > > azazel > > -- > Per iscriversi (o disiscriversi), basta spedire un messaggio con SOGGETTO > "subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxxxxxx -- ing. Guido Brugnara tel.+39(461)390804 fax.396028 Leader.IT S.r.l. (Leader Information Technology) Strada della Pozzata, 41 www.leader.it/srl 38050 Villazzano TRENTO (ITALY) info@xxxxxxxxx -- Per iscriversi (o disiscriversi), basta spedire un messaggio con SOGGETTO "subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxxxxxx