Un nuovo browser, basato su Wine, è il progetto di CodeWeavers: la società che offre prodotti commerciali per finanziare lo sviluppo del [non] emulatore di Windows su Linux e Mac OS X. L’intento è quello di creare un browser capace d’eseguire i controlli ActiveX che attualmente sono esclusi dai sistemi operativi diversi da Windows.

Lo sviluppo è ancora in una fase preliminare e, di conseguenza, non esistono immagini del browser. La domanda è scontata: perché produrre un software compatibile coi controlli ActiveX se la stessa Microsoft ne ha ridotto l’utilizzo su Internet Explorer? La risposta potrebbe essere in HTML5 e nell’esecuzione di applicazioni “native”.

Tuttavia, i linguaggi supportati dalla tag <canvas> di HTML5 sono già eseguibili dai moderni browser e per quanto riguarda i prodotti di Microsoft al massimo basterebbe Mono. Gli ActiveX hanno delle caratteristiche molto più invasive, però non esistono applicazioni così importanti da giustificarne l’utilizzo all’infuori di Windows.

Via | Phoronix

CodeWeavers è al lavoro per un nuovo browser compatibile con ActiveX é stato pubblicato su Ossblog.it alle 17:00 di martedì 01 maggio 2012.

Firefox supporterà la riproduzione dei contenuti multimediali coi codec provvisti dal backend di GStreamer. Ad accorgersi della novità è stato Fabian Deutsch, il creatore del plugin per OpenCL in Vala. È la conseguenza diretta del supporto ad H.264 di MPEG LA, però soddisfa molte più esigenze: è una funzionalità richiesta da tempo.

GStreamer è il backend predefinito per PulseAudio e Phonon su GNOME e KDE: è previsto da numerose applicazioni multimediali e sfruttato pure da LibreOffice e Apache OpenOffice. La scelta di Mozilla, su Linux, era scontata. Forse, un po’ troppo tardiva. Meglio tardi che mai è stato, infatti, il primo commento all’articolo di Deutsch.

Il supporto a GStreamer non è ancora stato ufficializzato da Mozilla. Tuttavia, la patch è già stata realizzata da Alessandro Decina e inviata al ramo di sviluppo del browser. Sebbene il bug tracking si riferisca a Fennec, l’introduzione del backend riguarderà anche la versione di Firefox per il desktop: in default, è disabilitata.

Via | Fabian Deutsch

Firefox supporta, finalmente, tutti i codec del backend di GStreamer é stato pubblicato su Ossblog.it alle 11:00 di venerdì 20 aprile 2012.

Lighspark 0.5.6, l’ultimo aggiornamento dell’alternativa open source a Flash Player di Adobe, è un rilascio interessante per almeno un paio di motivazioni. Anzitutto, introduce il supporto a Google Street View: una novità positiva, ma per molti versi superata dalla disponibilità di MapsGL che è scritta in HTML5, JavaScript e WebGL.

Un aspetto davvero intrigante di Lightspark 0.5.6 è il supporto alle Remote Procedure Call (RPC), che permette d’avviare alcuni tra i videogiochi più popolari sui social network. Ad esempio, Alessandro Pignotti parla di FarmVille: molti potrebbero considerarlo come un incubo. Tuttavia, per Lightspark è un progresso non indifferente.

Indubbiamente, la maggioranza dei servizi web – almeno, in via sperimentale – permette d’accedere ai contenuti multimediali da HTML5 e JavaScript. È il caso di YouTube, supportato soltanto parzialmente da Lightspark. I videogiochi, però, sono soprattutto in Adobe Flash e poter giocare con un’alternativa open source è una conquista.

Via | Alessandro Pignotti

Lightspark 0.5.6 supporta Google Street View, più alcuni videogiochi é stato pubblicato su Ossblog.it alle 13:00 di sabato 14 aprile 2012.

Firefox integrerà il supporto ad H.264, il codec proprietario del consorzio di MPEG LA: una decisione fondamentale «per competere nel settore mobile». Mozilla supporterà il codec in tutte le versioni del browser e nell’imminente Boot to Gecko (B2G). È un’opzione necessaria, soprattutto dopo l’eliminazione di Adobe Flash da Firefox.

La decisione doveva soltanto essere ufficializzata: la scorsa settimana, infatti, Andreas Gal aveva approfittato della discussione su H.264 per lodare la governance di Mozilla. Un aspetto interessante del supporto al codec – evitato per anni, dagli sviluppatori di Firefox – riguarda Google e Chrome: H.264 rimane comunque supportato.

Nonostante Mountain View abbia “nominalmente” rimosso il supporto ad H.264 dal browser di Android e da Chrome, il codec è supportato grazie a due fattori: la presenza di Adobe Flash e l’installazione a livello di sistema operativo. Firefox prevederà altrettanto. Essendo sottoposto a brevetto, H.264 non sarà distribuito col browser.

Via | LWN

Mozilla sceglie d’integrare il supporto al codec di H.264 su Firefox é stato pubblicato su Ossblog.it alle 13:00 di martedì 20 marzo 2012.

Ha fatto discutere la decisione, adottata da Canonical, di rimuovere il “supporto” a Firefox da Kubuntu 12.04 LTS. Tra virgolette, perché il browser di Mozilla continuerà a essere distribuito sulla variante di Ubuntu: le patch di firefox-kde-support non sono più mantenute, perciò il pacchetto è stato eliminato da Precise Pangoline.

Il problema sarebbe a monte, perché il codice che permetteva l’integrazione con KDE è stato sviluppato – e, quindi, rimosso – direttamente da Mozilla. Altre distribuzioni, come openSUSE, hanno optato per continuare a mantenere una patch di compatibilità. Kubuntu, al contrario, ne ha cessato lo sviluppo: sarà un danno molto relativo.

Cosa significa per gli utenti di Kubuntu? Quasi nulla, in realtà. Il pacchetto firefox-kde-support controllava degli aspetti come l’associazione dei protocolli, l’inserimento nei menù, ecc.: Firefox utilizza le specifiche di xdg per il desktop, supportate da KDE, e tutte le altre impostazioni possono essere configurate manualmente.

Via | Phoronix

Canonical ha eliminato il “supporto” di Firefox da Kubuntu 12.04 LTS é stato pubblicato su Ossblog.it alle 13:00 di lunedì 19 marzo 2012.

SPDY Indicator è una nuova estensione di Chrom* che visualizza, con un’icona nella barra degli indirizzi del browser, il supporto dell’omonimo protocollo di Google. Concepita da Guillermo Rauch, è rilasciata sotto licenza MIT su GitHub. SPDY (lett. “speedy”) è la soluzione di Mountain View per sostituire il protocollo HTTP sul web.

Adottato da tutti i siti di Google, SPDY è previsto da Chrom* e – a partire dalla versione 11 – è stato integrato in Firefox. Recentemente, il protocollo ha raggiunto anche Twitter. Sebbene la percentuale dei server che lo utilizzano sia tuttora esigua, sono in aumento i provider che lo offrono come opzione per i servizi di hosting.

Chrome SPDY Indicator offre una soluzione semplice ed efficace per verificare l’effettivo supporto del protocollo. SPDY richiede esplicitamente l’utilizzo di HTTPS, perciò l’icona dell’estensione può “colorarsi” soltanto in presenza di connessioni SSL o TLS. La maggiore rapidità di SPDY rispetto ad HTTP sarebbe un discorso a parte.

Via | Guillermo Rauch

Chrome SPDY Indicator visualizza il supporto al protocollo di Google é stato pubblicato su Ossblog.it alle 12:00 di lunedì 12 marzo 2012.

MIT App Inventor è la nuova incarnazione, gestita dal Massachusetts Institute of Technology (MIT) di Boston, dell’omonima piattaforma di Google. Ideata nel dicembre del 2010, è stata abbandonata da Mountain View a un anno esatto di distanza: App Inventor permette di realizzare applicazioni su Android, senza bisogno di programmare.

Per accedere alla beta di MIT App Inventor è sufficiente disporre d’un account con GMail, esattamente come in passato — sotto l’egida di Google. L’editor della piattaforma è molto simile a un What You See Is What You Get (WYSIWYG) per la creazione di siti web: ogni elemento è corredato da una semplice spiegazione del funzionamento.

Non è specificato quale browser utilizzare per MIT App Inventor. Tuttavia, la funzione di modifica dei “blocchi” è accessibile solo con Google Chrome. Per provare le applicazioni, ovviamente, bisogna installare l’emulatore di Android con una versione del Java Development Kit (JDK). MIT App Inventor presenta ancora qualche difetto.

Via | The H Open

Col MIT ha riaperto, in fase sperimentale, App Inventor per Android é stato pubblicato su Ossblog.it alle 12:00 di martedì 06 marzo 2012.

Rekonq 0.9, il browser di Andrea Diamantini che sostituisce Konqueror su KDE, ha finalmente raggiunto lo status di software stabile. Nelle scorse ore, in contemporanea alla nuova pagina sul portale KDE è arrivata la versione 0.90-1 di Rekonq per la gioia dei numerosi utenti.

Già disponibile per molte distro come Kubuntu, Chakra e ArchLinux, Rekonq porta con sé numerose funzionalità che migliorano sensibilmente l’utilizzo di questo interessantissimo browser, già presentato come alternativa al più famoso Konqueror. Tra le novità troviamo: il supporto alle web app, come avviene su Epiphany, l’introduzione dei suggerimenti durante la digitazione nella urlbar, una nuova pagina per le tab, la possibilità di condividere url e tasti via mail direttamente dal browser, un miglioramento delle performance e delle nuove scorciatoie da tastiera.

Altra funzionalità davvero interessante è la possibilità di sincronizzare i nostri dati personali come cronologia web, segnalibri e password tramite FTP, è inoltre previsto in futuro il supporto a ownCloud. Sicuramente Rekonq è un ottimo browser che se proseguirà il suo sviluppo secondo questi ritmi e questa politica, a mio parere scavalcherà il tanto amato Konqueror.

Via | KDE Apps

Rekonq: arriva la versione 0.90 stabile é stato pubblicato su Ossblog.it alle 13:00 di lunedì 05 marzo 2012.

Gnash, la soluzione open source alternativa a Flash Player, è stato aggiornato alla versione 0.8.10. L’annuncio del nuovo rilascio è arrivato a breve distanza dalla comunicazione di Adobe che, di fatto, limiterà la distribuzione del plugin a Google Chrom*. La novità più importante è il supporto di OpenVG per le immagini vettoriali.

L’aggiornamento del player apporta degli ulteriori miglioramenti all’interfaccia in Qt, ma Gnash non è ancora compatibile con le ultime specifiche di Adobe per il formato SWF e – di conseguenza – non può essere considerato alla pari con Lightspark. Quest’ultimo, ad ogni modo, supporta pure una modalità fallback per utilizzare Gnash.

Se HTML5 e JavaScript un giorno arriveranno probabilmente a sostituire le Rich Internet Applications (RIA)… il ciclo vitale di Flash Player è stato appena stimato in altri 5~10 anni. Un periodo di tempo abbastanza lungo perché l’imminente mancanza d’una versione standalone su Linux si faccia sentire. Gnash e Lightspark non bastano.

Via | Phoronix

Gnash 0.8.10 è stato rilasciato, all’indomani dell’annuncio di Adobe é stato pubblicato su Ossblog.it alle 16:00 di domenica 26 febbraio 2012.

Dartium, la versione di Chrom* che integra la Virtual Machine (VM) di DART, è disponibile al download su Linux a 64-bit e Mac OS X. Avevo accennato all’esistenza di questo browser introducendo Dart Synonym, l’applicazione web per tradurre il codice da JavaScript al nuovo linguaggio. Mountain View ha effettuato una scelta “curiosa”.

Prescindendo dall’esclusione di Windows, abbastanza prevedibile, i binari di Dartium per Linux sono compilati su Ubuntu/Lucid – la Long Term Support (LTS) di Canonical – a 64-bit. Una scelta poco comprensibile: Google sconsiglia d’utilizzare Dartium come il browser predefinito perché non pregiudichi un’altra installazione di Chrom*.

Comunque, i sorgenti di Dartium sono compatibili con qualunque distribuzione e su Mac OS X il problema non sembra porsi neppure coi binari. Rispetto all’enfasi posta da Google su DART, la cura dei dettagli di questo browser lascia a desiderare: forse, lo sviluppo è più indietro di quanto gli ingegneri di Mountain View prevedessero.

Via | Chromium

Dartium, il fork di Chrom* con Dart VM, è pronto su Linux e Mac OS X é stato pubblicato su Ossblog.it alle 10:00 di sabato 18 febbraio 2012.

Firefox, con l’uscita di Windows 8, inaugurerà una nuova interfaccia grafica su Metro. Il lavoro di Mozilla è ancora a uno stadio preliminare: l’intenzione, comunque, è apprezzabile — e potrebbe giovare ad altri sistemi operativi. Metro – a prescindere da Microsoft – è una grafica interessante, soprattutto perché è basata su HTML5.

Proprio questa mattina, infatti, elogiavo l’attenzione all’accessibilità del sistema operativo di Microsoft… resa possibile dall’integrazione di quegli standard del web che, fino a Internet Explorer 9, Windows ha rifiutato d’adottare. Firefox su Metro potrebbe essere molto più “performante” delle altre versioni per Linux e Mac OS X.

Una delle opzioni che Mozilla valuterà, ad esempio, è la creazione di Firefox in HTML, CSS e JavaScript: per fortuna, .NET è stato escluso a priori. L’abbandono di XUL potrebbe costituire un precedente interessante per eventuali porting di Firefox, sui sistemi operativi dei dispositivi mobili. Tuttavia, è presto per le valutazioni.

Via | The H Open

Mozilla ha intenzione di realizzare una versione di Firefox su Metro é stato pubblicato su Ossblog.it alle 15:00 di mercoledì 15 febbraio 2012.

Harmony è il nome in codice affidato da ECMA International al prossimo standard, in via di definizione, per JavaScript. Dal punto di vista degli sviluppatori, la disponibilità di Harmony costituirà – al contempo – una grande opportunità e un problema rilevante: ad esempio, la classica var sarà sostituita e integrata da let e const.

È soltanto uno degli aspetti che coinvolgono l’aggiornamento e, forse, neppure il più importante. Tuttavia, il numero di applicazioni che utilizzano JavaScript è in costante aumento – complice il prematuro successo di HTML5 – e iniziare ad adeguarsi alle modifiche, come avviene coi nuovi linguaggi di markup, è sempre un’ottima idea.

Google offre, attraverso Chrom*, la possibilità di verificare immediatamente le novità di JavaScript. Utilizzando gli ultimi snapshot di Chromium, la versione unbranded, si può accedere alle funzioni sperimentali di JavaScript da chrome://flags. Ecco perché la FSF è intervenuta sulle licenze degli script negli ultimi giorni giorni.

Via | Chromium

Harmony, il futuro di JavaScript, è subito in anteprima per Chromium é stato pubblicato su Ossblog.it alle 16:00 di martedì 14 febbraio 2012.

La Free Software Foundation (FSF) ha pubblicato una proposta per la specificazione delle licenze di rilascio del codice in JavaScript inserito sulle pagine web. Una soluzione discutibile, perché non è uno standard al quale attenersi: il metodo consiste nell’inserimento dei link alle licenze sulle pagine che contendono degli script.

L’espediente cerca di risolvere il problema dell’utilizzo di software proprietario in JavaScript, evidenziato nel documento di Richard Stallman. La marcatura proposta da quest’ultimo aveva, forse, una maggiore efficacia e – a costo di peccare d’eccesso di zelo – i webmaster dovrebbero implementarle entrambe. Le garanzie sono scarse.

La soluzione prevede la creazione d’una tabella, su qualsiasi pagina del sito, che elenchi tutte le licenze previste dai singoli script utilizzati. Questa tabella – marcata con l’identificativo jslicense-labels1 – dovrà contenere tre elementi: un link diretto allo script, uno alla licenza di rilascio e uno al download dello stesso.

Se sono presenti più script, dovranno essere compilate più tabelle: è il senso del numero 1 nell’identificativo. Ogni pagina sulla quale compaiono dovrà contenere un collegamento con rel="jslicense" alla tabella di riferimento. Il problema resta sul singolo script. Stallman pensava a una marcatura in linea, sotto forma di commento.

Per attenersi scrupolosamente ai consigli della FSF, un webmaster dovrebbe marcare gli script realizzati da terzi con la nuova soluzione e i propri con quella proposta a suo tempo da Stallman — magari, utilizzando la GPLv3 come licenza di rilascio. Un limite per entrambi i metodi è nel riconoscimento immediato da parte degli utenti.

Considerando l’utilizzo d’identificativi invariabili, il passaggio successivo potrebbe essere la creazione d’un sistema che evidenzi la presenza di software libero col browser. Come avviene, ad esempio, collegandosi a un sito che utilizza il protocollo HTTPS: perché sia efficace, tutti i produttori di browser dovrebbero prevederlo.

Qualcosa di simile, LibreJS, è stato realizzato da Loic Duros. Si tratta d’una estensione per Firefox che blocca selettivamente l’esecuzione di script proprietari. Il progetto è in fase sperimentale e non integra ancora il metodo consigliato dalla FSF. LibreJS è disegnata prendendo a modello il documento e la marcatura di Stallman.

Supportata dalla FSF, l’estensione di Duros dovrebbe essere la prima ad adeguarsi alla nuova soluzione. E, ahimè, potrebbe anche essere l’ultima: a prescindere dal contesto delle licenze, i produttori di browser tardano a realizzare dei controlli per il cd. “web semantico”… nonostante l’esistenza di numerosi progetti, basati su XML.

Se ci pensate, non esistono browser che supportano XFN — la marcatura per identificare le relazioni interpersonali tra gli autori dei contenuti sul web. Eppure, quest’ultima è utilizzata pure da Google nei risultati di ricerca. Si può dire più o meno lo stesso di RDFa. Sperare che prendano in considerazione le licenze è utopistico.

Via | The H Open

La Free Software Foundation è intervenuta sul problema di JavaScript é stato pubblicato su Ossblog.it alle 10:00 di lunedì 13 febbraio 2012.

Rekonq 0.9, il browser di Andrea Diamantini che sostituisce Konqueror su KDE, è stato presentato in anteprima agli sviluppatori. Avevo già parlato di due tra le novità più interessanti, ovvero l’integrazione delle applicazioni web – in parallelo al browser di GNOME – e il miglioramento dei suggerimenti per la barra degli indirizzi.

Un’altra funzionalità di Rekonq 0.9 è la possibilità di sincronizzare le informazioni personali (password, preferiti e cronologia del browser) da FTP. Il meccanismo, al momento, supporta soltanto le installazioni di ownCloud — la soluzione per il cloud computing basata su KDE. Molti contributori lavorano all’aggiunta di alternative.

Ulteriori funzionalità sono, piuttosto, delle soluzioni di problemi noti. Rekonq 0.9 corregge il recupero del browser al ripristino della sessione di KDE, migliora la gestione dei download, sistema l’aggiornamento delle icone nei preferiti. Il codice per l’utilizzo dei tasti d’accesso è mutuato da Arora, un altro browser su WebKit.

Via | Andrea Diamantini

Rekonq 0.9, un’anteprima per gli sviluppatori — da Andrea Diamantini é stato pubblicato su Ossblog.it alle 10:00 di martedì 24 gennaio 2012.

Chrom* Dev, il canale di sviluppo del browser di Google, ha appena acquisito il supporto a WebRTC per tutti i sistemi operativi. Quest’ultimo è un framework open source per la comunicazione in tempo reale da JavaScript su HTML5: non adotta una licenza approvata dalla Open Source Initiative (OSI). Il codice può essere ridistribuito.

Nello specifico, WebRTC – l’acronimo per Real-Time Communication – è la tecnologia sviluppata da Google su Hangouts, la funzione di videoconferenza in Google+. Mountain View ha sottoposto l’architettura alla valutazione di W3C e IETF perché WebRTC possa diventare uno standard. Il supporto “nativo” su Chrom* è un vantaggio per Linux.

Ad esempio, l’adozione di WebRTC renderà facoltativo il plugin di GTalk per il supporto a voce e video. La libreria è disponibile per Linux a 32-bit e 64-bit, ma soltanto pre-compilata nei pacchetti DEB ed RPM. WebRTC, al contrario, è più simile a Jingle: la tecnologia di XMPP per VoIP e videoconferenze. È una soluzione più duttile.

Se non intendete aggiornare Chromium compilandone i sorgenti o la distribuzione in uso non ne prevede i pacchetti, il supporto di WebRTC può essere ottenuto facilmente da Chrome Dev – la versione “brandizzata” di Google – su qualunque sistema operativo. Scaricato e installato il browser, bisogna lanciarlo con --enable-media-stream.

Prima di generare false aspettative, è bene sottolineare che per il momento WebRTC su Chrom* non serve praticamente a nulla. GTalk tuttora non l’ha adottato, perciò il plugin che ho citato rimane necessario per le videoconferenze. Hangouts di Google+, invece, implementa WebRTC lato-server — e il supporto del browser non è richiesto.

L’unica ragione per attivare WebRTC su Chrom* è lo sviluppo di applicazioni basate sul framework di Google. In particolare, è utile a chi volesse ospitare la propria soluzione su AppEngine: è stata redatta una breve documentazione per l’avvio del programma d’esempio. Agli utenti, invece, è sufficiente un browser che supporti HTML5.

Via | WebRTC

Chrom* Dev ha acquisito il supporto a WebRTC, il framework di Google é stato pubblicato su Ossblog.it alle 10:00 di giovedì 19 gennaio 2012.