Olimpo Informatico

[spacexplorer]

A tema smartphone FirefoxOS lo classifico a priori come WebOS: spazzatura,
Ubuntu Mobile non mi stà entusiasmando anche se potrebbe uscire qualcosa
di decente, in particolare quel che vorrei è:
* software libero, grazie (e fin qui pare ci siamo)
* "OS", GUI inclusa, framework a tema inclusi programmabile in Go e Python
* GUI decenti da disegnare sia in codice che con soluzioni RAD
* sistemi di sviluppo e packaging aperti come IPS/rpm-spec e Ubuntu/Apt

QML è interessante sul piano della disegnabilità, peccato che js non mi vada
giù e che IMO oggi puntare sul C++ per le applicazioni di terze parti sia un
po' un'idiozia dopo l'esperienza di Tizen/Sailfish/* quando ancora era MeeGo.

Il framework a tema mobile (API comode per GPS, SMS, funzioni di telefonia
ecc) di Ubuntu Mobile devo ancora vederlo, probabilmente ancora non c'è e
sarà in buona parte mutuato da Tizen&c cosa che non mi entusiasma troppo...

Il sistema di packaging infine è ancora ignoto...

'Somma sono parecchio freddino. In generale sento la necessità dello UNIX
2.0 ma per adesso Ubuntu (desktop/server) stà facendo un'integrazione di
tutto rispetto ed il software libero a tema è al vertice quindi mi va bene,
la web-mania ovvero cetriolo-ignoranza-mania non mi va proprio giù.

[mda]

@spacexplorer

Se non ti piace, non ti piace. Gustibus not disputandum est.

Al massimo su FirefoxOS posso informarti che non è WebOS neanche di striscio. Anzi assomiglia molto all'Android come architettura.

Guarda che Android è basato sul suo Chrome come GUI/Form.

Funziona benissimo senza collegamento internet grazie l'interfaccia Gaia. Si usa HTML5 come GUI (tramite Gecko) e non come browser. Qui esistono parecchie soluzioni RAID per fare le GUI in HTML5.

Certo avere già' un piede nel WEB, semplifica le applicazioni WEB oriented, ma io non lo vedo come un male. Funzionano sia in locale che su il web.

Usa Javascript/x (e non Javascript normale dei browser) che permette di fare vera programmazione come il Go e il Python. Certo solo alto livello e con sicurezza.

Il packegin dovrebbe essere quello del XPI (usato da firefox) modificato per un uso OS (nello specifico B2G) e non browser.

---------

Per Ubunto per smartphone, secondo me, stanno cercando una integrazione architetturale impossibile. Dubito che funzionerebbe su uno Smartphone in modo pratico.

Ciao

[spacexplorer]

mda, Firefox ed il suo mondo sono un mostro del passato, usato perché non
c'era altro. FirefoxOS al pari di WebOS è l'apoteosi dell'idiozia ovvero il
voler scrivere GUI come pagine web non rendendosi conto che le pagine web
sono un problema perché il concetto di "pagina" ed il paradigma per cui
furono pensati oggi non c'è più. L'web oramai non sono più documenti pubblici
consultati tramite un browser, sono applicazioni. Il fatto che ad oggi non ci
siano soluzioni moderne per scrivere GUI dovrebbe spingere a crearle non
portare un'assurdità altrove.

Puntare su AJAX, spingere js, *ml ecc è come dire che siccome i politici sono
corrotti tanto vale fare una dittatura almeno mangia uno solo e mazzola tutti
gli altri cattivoni.

Android è *ben diverso* da FirefoxOS e WebOS, ha un sotto-framework basato
su WebKit (ad esempio c'han scritto quella porcata che è Currents) ma la sua
UI è java, non javascript+html+css, Android non è pensato per essere una GUI
dentro un browser come FirefoxOS ed WebOS. "Avere un piede nell'web" vuol dire
avere un piede nella fossa poiché l'web2.0 così come viene inteso dai più e
spinto da molti commerciali è un ritorno ad un passato abbandonato perché non
più sostenibile, è un ripetere la storia perché non s'è voluto studiarla o si
pensa di potersene infischiare.

Poi certo ognuno la pensa a modo suo, per ora i risultati (disastri vari) di
certe idee si vedono, solo non sono pubblicizzati...

Su Ubuntu Mobile non vedo che integrazione impossibile ci sia: Android è una
distro GNU/Linux con l'userland semi-stravolto, Tizen è una distro come fosse
Ubuntu, solo tagliata per un uso su ferro "più piccolo". L'integrazione non
sarà certo la stessa Unity compiz-based di oggi, saranno le stesse API, così
un'applicazione per passare da desktop a mobile avrà solo bisogno di una GUI
mentre tutto il resto rimane uguale ed essendo la GUI separata dal resto
dell'applicazione il lavoro da fare è minimo.

[mda]

Qui penso che ti sbagli: FirefoxOS NON è WebOS, in quanto NON esiste il browser ma solo un motore HTML/XML. In Android sfruttarono Java per ridurre i tempi di progettazione, ma sempre Webkit (motore browser) che è usato.

Altre-si il modo di fare GUI NON con un approccio WEB o HTML che è vecchia (risalente al MS/DOS, UNIX e mainframe), Il nuovo QT4 per esempio cambia totalmente il suo approccio GUI (eppure era fenomenale) proprio per questo, anche .NET (usa le librerie IE) e Mono (quest'ultimo carica XmlRunner il motore di Gecko per le GUI) seguono la stessa strada, le GUI non web di Java non esistono più (esempio AWT) se non come approccio d'insegnamento. Posso snocciolarli tantissime librerie GUI del C e C++ oggi abbandonate anche se una volta usatissime proprio per questo limite, in Python ricordiamo wxwidgets, le GTK, ecc. .

Alla faccia dell'abbandono!

----

Per Ubunto posso darti ragione, ma prevedo tempi più lunghi e magari per il solo Tablet.

Ciao

[spacexplorer]

Vabbé non torniamo ai minestroni dai...

FirefoxOS non è WebOS, ma son fatti con lo stesso paradigma, in entrambi il
"browser" è un layer su cui girano tutte le applicazioni con interfaccia
grafica. Android al contrario *non usa* WebKit per tutte le applicazioni, è
solo un componente *a parte* che alcune applicazioni usano, tra l'altro
quelle che funzionano peggio come Currents o il Play store... Ovvero sia
WebOS che FirefoxOS mettono al centro dello sviluppo aborti tecnologici nati
come accanimento terapeutico per superare i limiti delle tecnologie web
classiche senza cambiare paradigma.

Sulle gui Java lascia perdere: solo per dare qualche nome Eclipse è scritta
in SWT, NetBeans in Swing ed un mucchio di altre applicazioni pure, AWT è
il primo toolkit Java ed oramai non lo si usa più manco per insegnare ma le
GUI Java sono dopo Qt e GTk le più diffuse. Qt, la cui ultima versione è la
5 non la 4 e la rivoluzione è l'aggiunta di QML/QtQuick, che non sostituisce
il classico peraltro sono diffusissime, le GTk sono alla base tanto per far
qualche nome del desktop di Ubuntu, Unity infatti è una shell di Gnome e
Gnome è scritto in GTk, per non parlare di Chrome per GNU/linux, Firefox su
GNU/Linux che come backend usa le GTk sopra il suo osceno layer... Le
librerie grafiche desktop sono poco evolute nel corso degli anni specie come
paradigma ma sono tutt'altro che morte...

Per Ubuntu son daccordo che i tempi saranno lunghi ma questo non è un gran
problema se il software è open ed esce ben prima del ferro, questo è infatti
una garanzia di successo per evitare di finire come l'ennesimo Bada, Tizen,
OpenMoko ecc!

[mda]

Se un a cosa non piace... Per me questo paradigma invece supera gli altri, avere un client-client o client-server, o solo client.

Comunque non tanto per puntualizzare ma per parlarne:

Le AWT di Ecplise e NetBin sono sostenute da librerie esterne (specie Eclipse grazie ad IBM) se no non si poteva sviluppare velocemente. Oramai in Java è un fiorire di System-GUI per Java proprio per i suoi limiti. la stessa Oracle ora pensa di adottarne uno, ma ancora non si è decisa, facendo secondo me un danno, perchè già adottando un sistema GUI come Mono lo risolverebbe, ma per ora Oracle/SUN afferma che oramai è solo web-application server quello che "tira".

Firefox non è scritto in GTK (in Linux) ma solo il motore (Gecko la specializzazione di Xulrunner) mentre la GUI (anche in Windows) è tutta XML+Javascript esattamente XUL+X-JavaScript. Idem Seamokey e Thunderbird e altri derivati. Qui semmai la scelta di andare verso HTML+javascript quando è più facile lo XUL che mi lascia deluso.

Delusione, la stessa decisione di Mozilla di continuare lo sviluppo su due versanti, MS-SDK per Windows e GTK per Linux, invece di uniformare tutto sotto GTK (funzionano anche sotto Windows) dato che sono più veloci, affidabili, ecc. ma anche che sarebbe più economico. Proposte oscene che aborro? C# e QT.

Le QML/QtQuick se vedi sono uno scopiazzamento XML-HTML/Javascript sotto altra forma proprio per estendere la GUI oltre il semplice Desktop (vedi KDE-Plasma con le QT), cosa non facile visto che ancora non riescono pienamente nel compito.

Infatti non dico che sono morte ma semplicemente ora risentono del limite di essere solo "locali".

Ciao

[spacexplorer]

gmpf mda, non voglio tornare alle polemiche di vari 3d precedenti...

Le AWT di Eclipse e NetBeans non sono AWT ma i loro successori ovvero le
SWIG di OpenJDK/SUN/Oracle e le SWT dell'IBM, entrambe esistono da una vita
e sono le uniche "system GUI" di Java. JavaFX come GTKHtml QtQuick ecc sono
un tentativo *abortivo* e in buona parte già abortito di rinnovare il
paradigma delle GUI desktop classiche. Il motivo dell'aborto è il tentativo
di utilizzare tecnologie (accrocchi) web nati come hack osceno per superare
i limiti delle tecnologie web pensate per documenti non applicazioni.

Di tutte queste "novità" l'unica che ha un qualche uso od interessa ad oggi
è QtQuick per lo più per il fatto di essere rest-based anziché x(ht)ml-based
in effetti non hanno un tubo di XML o HTML. Ma ha lo stesso difetto di
puntare su paradigmi inusabili. E lo scopo non è mai stato estendere la GUI
oltre il desktop quanto quello di rendere le GUI desktop programmabili da
gente con competenze di grafica ma poche o nulle competenze di programmazione
alfine di evitare l'impiego di risorse nella realizzazione di noiose GUI al
posto di scrivere il core dell'applicazione.

Firefox né Gecko sono scritti in GTk: xul(runner) usa le GTk per disegnare
la GUI su GNU/Linux. Ovvero Firefox al pari delle WxWidgets wrappa alcune
librerie grafiche di sistema per essere "multipiattaforma". In altri termini
non è una GUI ma un wrapper, un'API comune a varie GUI che nasconde queste
al programmatore finale.

Il limite dell GUI desktop è che ce ne sono tante, ognuna a modo suo, e che
scrivere una GUI richiede un bel po' di codice noioso da scrivere ma non
abbastanza facile per essere scritto da un'artista/grafico al posto di un
programmatore. Il limite delle WebUI è che queste sono un tentativo di far
evolvere uno strumento nato come "pagina"/"documento" in un'applicazione,
tale tentativo deriva da due cose: scrivere un documento è più facile di
scrivere applicazioni quindi trovi tanti bipedi incompetenti&felici di poter
realizzare obbrobri improponibili e dall'altra parte perché se si riesce a
far tornare in auge i vecchi mainframe si riesce a mantenere ancora in
catene, molto più robuste 'stavolta, l'utente finale e tenere il mercato in
mano a una manciata di big.

[Zeus News]

Google dichiara guerra alle password: credi anche tu che una chiavetta USB coi dati dell'utente sia più sicura dei sistemi attuali?

[mda]

[spacexplorer]

mda, io son sempre disposto a parlare, ma io tuo stile e le notizie che porti
non rendono molto facile il dialogo...

Alcune precisazioni: Eclipse e Netbeans sono IDE e più in generale delle
piattaforme di sviluppo scritte in Java. Non in C in alcuna loro parte se
non eventuali plugin o progetti di terze parti che usino librerie JNI.
Puoi scrivere software in C, C++, Python, Ruby ed un mucchio di altri linguaggi
sia con Eclipse che Netbeans come con KDevelop, Anjuta, Visual Studio ed un bel
po' di altri IDE.

Sia SWIG che SWT prendono spunto ed in parte si basano su AWT e il C non
c'entra un tubo: SWT come SWIG come AWT sono *librerie grafiche* della
piattaforma Java, girano sulla jvm e servono a creare interfacce grafiche
scritte in codice Java.

JavaFX non implementa affatto codice web, è solo un modo diverso di sviluppare
GUI desktop basato un un linguaggio, JavaFX appunto, il cui obiettivo era
rendere più rapido e meno noioso lo scrivere GUI. Il suo sviluppo è tanto
promettente da considerarsi oramai del tutto morto. L'unico lavoro noto e
rilevante era il Project Renaissance che doveva diventare un nuovo e gestibile
OpenOffice, il progetto è morto ancor prima che la SUN fosse comprata da
Oracle.

QtQuick è l'ennesimo modo alternativo di scrivere GUI mezzo riuscito mezzo
assurdo in buona compagnia con JavaFX e GTKHtml. L'unico motivo per cui è
ancor vivo anche se ben poco usato è che è vagamente rest-based anziché xml
based. Ha il difetto *letale* di essere integrabile in altri linguaggi giacché
la GUI non è l'applicazione ma solo la sua interfaccia cogli umani, come lo è
un cobra affamato in una nursery. Ad oggi il motivo per cui tanti spingono per
l'impiego di tecnologie web sul desktop è proprio l'assenza di soluzioni comode
per gli impieghi moderni lato desktop. Peccato che non esistano manco lato
web... Ovviamente alcuni big dell'web son ben contenti dell'idiozia di una
bella massa di bipedi per spingere un po' di più i loro cetrioli.

Per rispondere "python che fornisce gui che cambiano di stato dove son messe"
è semplicemente incomprensibile, un po' come dire che: "le cucurbitacee
permettono di migliorare la costruzione di riviere grazia alla loro forma"
Su explorer.exe non so che c'entri: il fatto che un browser sia usato per
filemanager e desktop manager non c'entra nulla con le tecnologie web, anche
nautilus è usato per gestire il desktop e allora? Mica il desktop è scritto in
js+html eh, semplicemente è *renderizzato* ovvero disegnato dallo stesso
processo che può renderizzare pagine web, coll'ottimo risultato che appunto
se il processo si pianta pianti l'intero desktop. Microsoft è infatti famosa
per la sua tecnica...

'somma di cosa parliamo (a parte l'essere assolutamente OT)?

[mda]

Adesso capisco il perchè dici quello che dici. le tue notizie sono parziali e quindi pensi che siano complete.

Va bé allora è inutile parlarne dato anche che ognuno rimane su sue posizioni.

Ciao

[spacexplorer]

le "mie notizie" sono parziali?! Mda io non voglio flame ma tu li cerchi
proprio! Hai scritto una massa di idiozie in pseudoitaliano smentendoti
da solo da un post all'altro, fai tu.

Qui non c'è da rimanere sulle proprie posizioni, qui c'è da separare ciò
che esiste da ciò che è elaborazione fantasiosa!

[mda]

Ciao che è meglio tanto siamo OT!