Il proliferare di segnalazioni di browser basati su WebKit porta a pensare che nel giro di pochi mesi ci troveremo a dover scegliere tra numerose alternative, con questa panoramica cerco di fare un po’ di ordine tra le principali possibilità, sia in KDE che in GNOME.
1. La situazione in KDE
KDE 4 si conferma come il regno delle possibilità. Un po’ perché non si è riusciti a prendere una decisione sul motore di resa HTML di Konqueror (ci sono vere e proprie fazioni KHTML vs WebKit, ognuna con rispettabilissime posizioni), un po’ perché gli stimoli sono davvero tanti e le potenzialità delle librerie Qt troppo golose per non sfruttarle.
Ecco dunque allo stato attuale la situazione di questi piccoli browser che al momento scalpitano in direzioni un po’ confusionarie, ma che in futuro…
Arora
Minimale ma non troppo, basato esclusivamente su Qt/WebKit (dunque non esattamente KDE). Arora è forse il progetto che più di tutti ha incoraggiato a provare WebKit: resa quasi perfetta e interfaccia funzionale che ricorda Firefox con il suo campo di ricerca a destra (ma che supporta solo Google). Niente estensioni di nessun tipo, flash dovrebbe esserci ma nella mia installazione non funziona.
Ho spesso scritto di Arora e ha già un seguito non indifferente e lo percepisco perché ogni volta che esce una nuova versione mi viene subito chiesto di inserirla nel pollyrepo. Ah, a proposito: non ne ho mai dato notizia ma ho impacchettato anche l’ultima versione (al momento la 0.6) ;)
ReKonq
Se vi piace Arora dovreste amare ReKonq, che è essenzialmente Arora + KDE. Stessa interfaccia ma con il supporto alle comodità di KDE, stessa resa e stessa semplicità di Arora. L’ho segnalato pochi giorni fa in “Andrea Diamantini rilascia ReKonq, browser WebKit-KDE”
Lo sviluppatore di rekonq è l’italiano Andrea Diamantini e il progetto ha da pochissimo cominciato a circolare, ma ha attirato già l’attenzione di molti, addirittura come possibile alternativa niente meno che a Konqueror!
Webbie
Ovviamente sempre Qt/WebKit, ma ispirato direttamente ad una caratteristica di Google Chrome in quanto se una delle schede di Webbie va in crash, non uccide l’intera applicazione perché ogni tab è un processo a se stante. Non solo: una notifica si offre prontamente di ricaricare la scheda «andata a male»:
La cosa interessante di Webbie è che al momento non ha nessuna pretesa di diventare un vero browser ma nasce come terreno di sperimentazione per fornire caratteristiche che una volta pronte potranno essere condivise da altre applicazioni, specialmente Konqueror e/o Rekonq.
Konqueror
Chi di voi è abbastanza navigato1 da ricordare quando Netscape su Linux era talmente vergognoso che non disdegnavamo un giretto con Konqueror? :)
Beh con KDE 4 Konqueror ha subito un forte ridimensionamento. Da file manager camaleontico capace di leggere qualsiasi file e web browser ufficiale di KDE… adesso con Dolphin è stato scalzato dal primo ruolo e sembrerebbe vacillare anche nel secondo, non si sa bene a favore di chi. Parte del problema potrebbe essere dovuto al fatto che a mio avviso si è stati si è troppo indecisi sul supporto a questo (KHTML) o quel (WebKit) backend per motivi un po’ politici.
La situazione attuale è che KHTML è il motore predefinito in un KDE vanilla, ma è facile ottenere un Konqueror WebKit perfettamente funzionante e abbastanza stabile.
2. La situazione in GNOME
Il motore di resa KHTML classico per GNOME è GtkHTML. Semplice e con il modesto obiettivo di rendere una occasionale pagina d’aiuto nel manuale delle applicazioni, email HTML e cose del genere. L’aspetto vantaggioso è sempre stato la leggerezza: sono basati su GtkHTML browser molto minimali e soprattutto il gestore di posta Evolution.
Per un lungo periodo il team ha flirtato con Gecko, ma la cosa è finita per incompatibilità di caratteri. Il miglior esempio della burrascosa relazione deve essere stato Galeon, un browser che forse nessuno dei nuovi utenti ricorda/conosce ma che fino a qualche anno fa rappresentava il massimo che si potesse ottenere in GNOME.
Infine ecco WebKit-ex-KHTML, che probabilmente non sarebbe mai stato preso in considerazione se Apple non ci avesse messo su il marchio, e che adesso la fa da padrona nei piani di sviluppo dell’intero desktop. E a ragione.
Midori
L’ho installato e provato diverse volte, anche perché è disponibile in un comodo pacchetto per chi usa Ubuntu. Midori (blogger: date un po’ di link/visibilità alla sua pagina!) offre le funzionalità indispensabili alla navigazione e rappresenta il modo più comodo e semplice per provare WebKit/GTK.
Purtroppo non direi che si distingue per la stabilità. L’ultima volta che ho provato a recensire Midori è morto dopo aver aperto la homepage di pollycoke… Resta un progetto interessante con cui mettere alla prova le varie componenti che si presume sarano in ottima forma per essere inserite in un altro progetto: il browser ufficiale di GNOME.
Epiphany
Eccolo, il browser ufficiale di GNOME. Semplice, razionale e con il timido supporto alle estensioni anche più funzionale di quanto ci si aspetterebbe. Quando ero un fanatico di GNOME usavo Epiphany al posto di Firefox perché più leggero, ma sempre basato su Gecko. Anche la versione che potete usare in questo momento è basata su Gecko, ma in passato ho scritto delle istruzioni per compilare Epiphany WebKit che dovrebbero funzionare ancora (fatemi sapere se non è così).
Dalle prossime versioni di GNOME tutto dovrebbe cambiare: il nuovo motore predefinito di resa HTML per Epiphany sarà WebKit e allora probabilmente avremo sul serio un gran browser con alcune caratteristiche interessanti come la gestione dei segnalibri tramite etichette, la barra degli indirizzi intelligente come quella di Firefox e altre sciccherie varie, ma soprattutto la migliore integrazione con il resto dell’ambiente.
3. Conclusioni
Da questa rapida panoramica si può vedere che le scelte non mancano insomma. Sia in GNOME che in KDE sono state battute differenti strade e sperimentate diverse soluzioni. Posso trarre alcune considerazioni che vi obbligo simpaticamente a condividere:
- Nessuna di queste alternative mostra ancora un decimo delle funzionalità di Firefox, che per quanto pesante e sempre un po’ alieno resta incontrastato il browser.
- Lasciando stare la stabilità, chi di voi non ha mai usato una delle infinite estensioni di Firefox? Oltre al backend ci sarà da elaborare un sistema di estensioni almeno paragonabile a quello che ha fatto la fortuna di Firefox
- Il vero problema non sta nelle sperimentazioni con l’interfaccia, ma allo stato attuale il tutto si risolve ai port di WebKit per GTK+ e per Qt, dunque “Webbie/Arora/Rekonq/Konqueror” da una parte e “Midori/Epiphany” dall’altra.
- Molte di queste alternative resteranno relegate al ruolo di sperimentazione e serviranno quasi esclusivamente ad introdurre o testare nuove funzionalità per Konqueror (con qualche riserva) in KDE ed Epiphany in GNOME.
- In tutto questo brulicare di alternative non c’è da dimenticare Google Chrome, che sopra la pietra di WebKit sta costruendo una cattedrale2 di funzionalità che già cominciano ad essere imitate (vedi Webbie)
Da tutto questo fermento al momento l’utente finale non trae nessun reale guadagno insomma, e sarà così almeno finché i port del backend non saranno maturi e paragonabili all’originale. La buona notizia è che ci stiamo avvicinando all’obiettivo.