Quando è stato avviato il porting di Chromium su Linux, il cuore open source del browser Chrome, la scelta relativa a come implementare la parte grafica è ricaduta su GTK e non su QT. La motivazione principale della scelta sembra essere dovuta a "problemi di convivenza" tra la licenza di QT, all´epoca GPL, e quella di Chromium, ovvero la BSD.
Gli sviluppi sono proseguiti, quindi, con l´intento di avere un browser GTK-Based, e ad oggi l´applicativo di test di Chromium (chiamato "test_shell") consente già di renderizzare le pagine Web in maniera discreta. Sul Wiki del progetto è possibile trovare anche uno schema che riassume come viene gestita la catena di rendering della parte grafica.
Il recente annuncio di Nokia a proposito dell´adozione della licenza LGPL per QT 4.5 non è passato inosservato. È stata una occasione per molti della comunità di Chromium di riprendere il discorso sul come implementare la gestione della grafica su Linux.
Certamente dal punto di vista legale sembra che le cose si facilitino, la convivenza tra il mondo QT e quello Chromium sembrerebbe possibile. Detto questo, però, gli sviluppatori Google e lo stesso Project Management stanno valutando attentamente se conviene cambiare framework grafico.
La parte grafica di Chromium è organizzata secondo Views, "codice portabile", e Widgets, "codice platform dependent", con le Views implementate utilizzando i Widget. Le Views sono quello che vediamo nei diversi tab, quindi le pagine Web, mentre i Widgets sono i singoli componenti grafici. Questo approccio rende certamente facilmente sperimentabile l´adozione di framework grafici diversi, ma ciò non giustifica un cambio di rotta improvviso.
Ad oggi, scrivere una applicazione QT-native non sembra garantire piena compatibilità con KDE 4.x, anzi sembrano esserci problemi di convivenza. Lo stesso non vale tra GTK e Gnome. Lo sviluppare Chromium sia per QT che per GTK "spaventa un po´ tutti", soprattutto per lo sforzo di testing richiesto. Inoltre ricominciare con QT potrebbe costringere ad una revisione dei piani di sviluppo, con ritardi sull´attuale roadmap.
Il principale punto a favore di QT è l´elevata portabilità tra piattaforme, visto che esistono versioni della libreria sia per Windows che per Linux, e che è stata annunciata una versione a 64 bit per Mac. A questo si aggiunge il fatto che l´engine WebKit, che si occupa dell´interpretazione, gestione e rendering delle pagine Web, di base è già integrato in QT.
Cosa accadrà? Potrebbe costituirsi un gruppo di "tenaci sviluppatori" disposti a provare l´accoppiata Chromium+QT ad ogni costo?