Da quando è stato annunciato lo “switch“ per il backend di Epiphany, in molti si sono cimentati nel tentativo di compilarlo (e anche io), prima del rilascio ufficiale. Soltanto alcuni, però, hanno effettivamente provato il test dell’Acid3: ovviamente, ho fatto altrettanto, ma il mio risultato è stato sensibilmente diverso. Credo d’avere la spiegazione, ecco il motivo di questo mio post… che, ovviamente, resterà (e le richiedo esplicitamente) aperto a ogni feedback.

Il punto è che l’Acid3 andrebbe effettuato mantenendo le opzioni predefinite nel corso della compilazione/installazione del browser in oggetto: motivo, questo, che darebbe una spiegazione credibile dei diversi risultati ottenuti dal benchmark. Infatti, nelle istruzioni di compilazione del backend sono descritte delle variabili aggiuntive che, personalmente, non ho utilizzato. E che potrebbero influenzare il punteggio.

Si parla, infatti, di supporto sperimentale alle SVG e al tag <video> dell’HTML5, oltre a ulteriori opzioni irrilevanti (da questo punto di vista). Per questo motivo, se si utilizzassero queste variabili nel corso della “costruzione” di WebKit, si otterrebbe - successivamente - un risultato “falsato” con il browser. Posto che ciò non sarebbe comunque sufficiente per valutarne l’efficienza, andrebbe comunque considerato che Epiphany/WebKit non è ancora “stabile” (sarà rilasciato soltanto con GNOME 2.24).

Tra i vari servizi “web 2.0“, Flickr - per quanto riguarda la pubblicazione delle proprie fotografie online - è indubbiamente uno dei più utilizzati e apprezzati dagli utenti: qualche giorno fa, ho appreso della possibilità di accedervi via FUSE. Ebbene, per i possessori di Ubuntu/Hardy, questa procedura è molto più semplice di come venga descritta sul sito di sviluppo di FlickrFS.

Già, perché sia il filesystem che la sua interfaccia gestionale, DFO, sono nell’“universo” di Ubuntu (almeno, dalla versione 8.04 LTS), cosicché è sufficiente un semplice comando per ottenere entrambi. Vediamo quale:

$ sudo aptitude install dfo flickrfs

E le eventuali dipendenze saranno soddisfatte automaticamente. A un primo approccio, l’unico gap evidente con la gestione diretta dal sito riguarda l’assegnazione dell’immagine a una mappa: per il resto, una volta autorizzata l’applicazione ed effettuato il login - tanto i possessori di account “free”, quanto quelli della versione “pro“ - si possono controllare tutte le feature, con l’agilità consentita dal “drag’n'drop“.

Premesso che non ho alcuna pregiudiziale verso questo browser - anzi, fino a ieri ne sono stato un convinto sostenitore (anche in tempi “non sospetti”)! -, mi duole dover constatare di non essere l’unico ad avere diversi problemi con Firefox 3 Beta 5: soltanto che, diversamente da altri, non credo che sia sufficiente garantirne la “stabilità”… per ovviare ai tanti e tali problemi che ingenera.

Già, perché le applicazioni di terze parti “affette” da un’idiosincrasia nei suoi confronti non sono proprio marginali: anzitutto, dal rilascio stabile di “Hardy Heron”, Firefox stesso non ha mai “ricordato” le sessioni… il ché significa che - qualora anche voi, come me, apriate diverse schede contemporaneamente - sarete costretti a salvare tutte le pagine come segnalibri per evitare di perdere delle risorse utili.

Ma non è tutto: a prescindere dal fatto che lo scegliate o, meno come browser di default (in ogni caso, Ubuntu/Hardy lo imposta come predefinito), non sarete in grado di salvare i cookie di Mugshot, rendendo così pressoché inutilizzabile anche l’OnlineDesktop - quest’ultimo, ancora in fase di sviluppo - di GNOME. E, se ciò ancora non fosse sufficiente, sono diverse le estensioni incompatibili con questa versione di Firefox. Una scelta “azzardata”?

L’icona-simbolo di questa applicazione è talmente bella da essere stata “integrata” nella pagina principale di GNOME, eppure - nonostante si tratti di un progetto molto interessante! - riguardo l’applicazione in sé ci sarà ancora molto lavoro da fare. Sì, perché nonostante l’ottima integrazione con il DE e il supporto a tutte le webcam che già funzionano con Linux, sussiste un piccolo “problema” che ne inficia l’utilizzo.

Ahimè, sto parlando del supporto audio per le registrazioni: inizialmente, credevo si trattasse di una mia dimenticanza, avendo appena [re-]installato il sistema e non avendo ancora aggiornato i codec GStreamer… benché fosse evidente la mancanza di un “pannello” relativo al flusso audio (non ci sono equalizzatori). Ovviato al problema, ho dovuto constatare che si tratta effettivamente di una “dimenticanza” dell’applicazione!

È evidente come sia un problema non da poco, considerando che - per quanto mi riguarda - volevo utilizzare Cheese per la registrazione di un vlog tecnico: tra gli aspetti più interessanti, comunque, c’è la possibilità di salvare in default in formato OGG (ma non è normativo), suggerito dal W3C come futuro “standard“ per il web. Non ci resta che attendere ulteriori sviluppi del programma: sarebbe un peccato essere costretti a “importare” l’audio manualmente!

Dalla prima volta che ne ho sentito parlare - benché inizialmente fossi “riluttante”… -, ho sempre coltivato una certa curiosità per il “cambio di rotta” di Epiphany: inizialmente non era così “facile” ottenere il risultato voluto, mentre con il rilascio stabile di GNOME 2.22 (e l’inizio della fase di sviluppo della versione successiva) via SVN c’è già tutto l’occorrente per compilare il browser con backend WebKit [fig.] al posto di Gecko.

Partiamo dal presupposto che le istruzioni “ufficiali” sono lacunose e in parte errate: l’aspetto più evidente è che, per compilare il browser, viene indicato configure mentre nell’archivio è presente autogen.sh. D’accordo, è ben “poca cosa”, ma non pensate che ci siano linee guida decenti anche per quanto riguarda le dipendenze da installare! Cominciamo da queste.

$ sudo aptitude install bison epiphany-browser flex gperf \
gtk-doc-tools libgconf2-dev libgnome-desktop-dev libgnome2-dev \
libgnomeui-dev libgtk2.0-dev libgtk-directfb-2.0-dev \
libiconv-hook-dev libicu-dev libcurl4-gnutls-dev libjpeg62-dev \
libpng12-dev libqt4-dev libsqlite3-dev libxslt1-dev

Come potete notare, sarete costretti a installare epiphany-browser, che anche su Ubuntu/Hardy richiede il pacchetto (a dire il vero “nuovo”) epiphany-gecko: questo, ahimè, ci costringerà a installare in /usr… a meno che non decidiate di compilare tutto il browser via jhbuild. Un altro problema potrebbe riguardare gli aggiornamenti con apt: se, infatti, avete dei repository che includono pacchetti dall’SVN di GNOME, potreste essere costretti a “bloccare” la versione appena installata (non ne sono sicuro)!

Sì, perché noi di fatto “sovrascriveremo” il backend predefinito: ovviamente non mi assumo alcuna responsabilità sul risultato. Ad ogni modo, preparatevi qualcosa per “ingannare” l’attesa… perché, prima di procedere con Epiphany, dobbiamo scaricare tutto il “pacchetto” di WebKit (operazione, questa, che richiede una mezz’oretta buona). Ovviamente, saremo costretti a compilare anche questo:

$ svn co http://svn.webkit.org/repository/webkit/trunk webkit
$ cd webkit/
./autogen.sh --prefix=/usr --exec-prefix=/usr --libdir=/usr/lib64 \
&& make && sudo make install && make clean

Si noti che per consentire la corretta verifica dell’Acid3, ho lasciato le impostazioni di default, tralasciando il supporto sperimentale a video e SVG. Questo è il “minore” dei problemi, dal momento che il browser presenta ancora delle “falle” - ad esempio, le schede relative alle opzioni di personalizzazione non sono complete! - ed essendo su 64-bit sarò costretto a usare nspluginwrapper (di cui non parlo qui) per far “girare” Adobe Flash. Procediamo.

$ svn co http://svn.gnome.org/svn/epiphany/trunk/ epiphany-webkit
$ cd epiphany-webkit/
$ ./autogen.sh --prefix=/usr \
--exec-prefix=/usr --libdir=/usr/lib64 –with-engine=webkit \
&& make && sudo make install && make clean