Oxygen-Gtk3, la versione del tema di KDE ricreata da Hugo Pereira Da Costa in Gtk+3, è alla versione 1.0. Annunciato ad aprile – in via sperimentale – su KDE Software Compilation (SC) 4.7, Oxygen-Gtk3 1.0 ha raggiunto un discreto livello di maturità. Da Costa lo considera tuttora instabile, per via delle poche applicazioni provate.
Il tema affianca l’omonimo Oxygen-Gtk scritto per le Gtk+2. Se quest’ultimo è particolarmente utile con Chrom*, Firefox o The GIMP, Oxygen-Gtk3 migliora l’aspetto di applicazioni come gEdit su KDE. Certo, al momento è abbastanza difficile che un utente del desktop environment in Qt abbia dei programmi del genere sul proprio sistema.
È, piuttosto, un investimento sul futuro: The GIMP, ad esempio, superato l’impasse della versione 2.8 sarà riscritto in Gtk+3. La questione dei browser, per riprendere le applicazioni citate, è più complessa. Le versioni in Qt di Chrom* e Firefox, infatti, potrebbero essere realizzate addirittura prima della transizione alle Gtk+3.
Via | Hugo Pereira Da Costa
Lo sviluppo delle Gtk+3 non riguarda esclusivamente i sistemi operativi UNIX–like. Uno tra i porting più importanti è quello per Windows: il punto in comune è l’utilizzo degli stili dei CSS3. Alexander Larsson, che si occupa della manutenzione, ha pubblicato le Gtk+ 2.24.8 – è «il migliore rilascio di sempre» – e lavora alle Gtk+3.
Lo stato dell’arte non è certo paragonabile a quello delle librerie per Linux, ma l’avanzamento nello sviluppo per Windows propone delle novità rilevanti. L’engine dedicato a Win32 sarà completamente rimpiazzato dai CSS, riducendo le discrepanze tra le diverse implementazioni delle Gtk+ che ne guadagneranno a livello di prestazioni.
Uno dei programmi più importanti per le Gtk+ su Windows è The GIMP: l’applicazione effettuerà il passaggio al nuovo ramo delle librerie soltanto con la versione 3.0. All’appello mancano ancora la 2.8 attesa nei prossimi giorni e la 2.10. È il momento giusto per definire tutti i dettagli del porting. Larsson ha molto lavoro davanti.
Via | Alexander Larsson
Sono appena state rilasciate le Gtk+ 3.3.4, una versione di sviluppo che determina un punto di non ritorno per Beagle: il framework per la ricerca sul desktop è stato rimosso definitivamente da GNOME in favore di Tracker. Una scelta che sarebbe potuta arrivare quattro anni fa. L’altra novità riguarda il supporto ai CSS3 per i temi.
Tracker permetteva la ricerca semantica e il tagging di cartelle e documenti già nel 2007 con GNOME 2.2x o successivo. Un plugin per Nautilus, in Python, permetteva quanto Canonical ha dichiarato di proporre su Ubuntu/Precise: la possibilità di “taggare” i contenuti non dipende dalla distribuzione, bensì dall’aggiornamento di GNOME.
Il passaggio a Tracker garantisce la compatibilità con Nepomuk, l’infrastruttura per il desktop semantico implementata inizialmente da KDE. Chissà se scegliere Tracker quattro anni fa avrebbe giovato allo sviluppo di GNOME 3.x. Ad ogni modo, meglio tardi che mai: non saremo costretti a configurare due motori di ricerca sul desktop.
Continua a leggere: Le Gtk+ 3.3.4 rimuovono il supporto a Beagle guardando ad HTML5/CSS3
Ristretto, l’applicazione utilizzata su Xfce per visualizzare le immagini, inaugura un ciclo di sviluppo rinnovato col rilascio della serie 0.1.x. L’ultimo aggiornamento del programma non contiene novità “rivoluzionarie”: è essenzialmente una release di bug fixing che migliora l’affidabilità di Ristretto evitando blocchi improvvisi.
Stephan Arts, lo sviluppatore del software, ha impiegato gli ultimi sei mesi a correggere i problemi più fastidiosi. Ristretto 0.1.x reintroduce il dialogo delle proprietà dei file, aggiusta il posizionamento del mouse durante lo zoom e inserisce nuovi tasti di scelta rapida per la navigazione da tastiera. Il più stabile di sempre.
La presentazione di Ristretto 0.1.x è stata anche l’occasione per un’amara conferma: il programma non supporterà le operazioni più comuni nella correzione delle immagini. Come la rotazione, il taglio e il ridimensionamento. L’unica possibilità, in questa direzione, sarebbe introdurre un sistema di plugin: Arts accetta dei consigli.
Via | Xfce
Clutter 1.8, la libreria per interfacce grafiche apprezzata su Tizen (ex-MeeGo), è stata rilasciata con qualche giorno d’anticipo su GNOME 3.2: Emmanuele Bassi, tra gli sviluppatori, è intervenuto a riassumerne le funzionalità. L’aggiornamento è importante perché introduce Cogl 2.0, componente essenziale della compilazione di GNOME.
Cogl è una libreria condivisa per la programmazione orientata ai processori grafici su OpenGL: è separata da Clutter e consente l’implementazione su altri progetti e il backend di Gdk è parte del compositing di GNOME Shell. Il risultato, per Mutter, è un effetto d’elevate prestazioni sia su OpenGL con il backend di X11, sia su Gdk.
Il futuro è piuttosto intrigante per i dispositivi mobili, non soltanto per l’utilizzo di Cairo (che supporta EGL/GLES) a disegnare le texture con Clutter. L’aggiornamento introduce delle gestualità utili a integrare il multi-touch, tanto per Tizen, quanto per GNOME. Clutter 1.10 è previsto per marzo e il trunk è già stato avviato.
Via | Emmanuele Bassi
Opera Next 12.00-1065, cioè il canale di sviluppo del browser, introduce il supporto sperimentale alle librerie Gtk+3 e in particolare ad Adwaita, il tema predefinito di GNOME 3.1. L’obiettivo è quello di migliorare l’integrazione di Opera con GNOME Shell e i risultati sono già abbastanza soddisfacenti, per il menù delle preferenze.
Sempre citando il menù, tuttavia, Opera Next non sembra “digerire” molto il compositing di Mutter. Con tutte le attenuanti del caso, trattandosi di una versione sperimentale, sono molti gli artefatti generati passando da una tendina all’altra. Un’attenuante è lo stato almeno altrettanto instabile del window manager su GNOME 3.1.91.
A prescindere dallo stato dell’arte del porting, Opera è il primo dei browser più diffusi a considerare il passaggio alle Gtk+3: Mozilla è al lavoro sulle patch da prima dell’uscita di GNOME Shell mentre Google non sembra ancora interessata all’aggiornamento. Epiphany resta l’unico browser a mostrare una certa maturità sulle Gtk+3.
Via | Opera
LXDE non avrà grandissimi problemi nel passaggio alle Gtk+3 almeno stando alle prove di compilazione effettuate da Andrea Florio su openSUSE. Il desktop coreano è tuttora basato sulle Gtk+2, librerie grafiche destinate a diventare obsolete entro pochi mesi e già superate grazie all’uscita di GNOME Shell. Non sarà comunque immediato.
Tra tutti i pacchetti disponibili soltanto cinque non terminano correttamente la compilazione con le Gtk+3. Purtroppo, si tratta di componenti fondamentali di LXDE: passino pure gpicview ed lxmusic, tuttavia libfm, pcmanfm ed lxpanel sono dipendenze essenziali per il desktop. E il problema riguarda direttamente lo sviluppo di LXDE.
Il desktop è stato realizzato partendo dalle Gtk+2 e, nonostante la retro-compatibilità delle Gtk+3, serviranno degli “aggiustamenti” nel sorgente di LXDE. Le modifiche dovrebbero corrispondere a nuove funzionalità per il file manager. Florio, intanto, chiede aiuto agli sviluppatori per portare LXDE con le Gtk+3 su Debian e Ubuntu.
Via | openSUSE Lizards
The GIMP ha ricevuto nuovamente la modalità a finestra singola nell’archivio di sviluppo su Git. È un aggiornamento interessante, perché avvicina al rilascio di The GIMP 2.8: la roadmap non è ancora stata modificata con l’inclusione della Single Window, tuttavia la prossima release potrebbe arrivare molto prima del mese di dicembre.
Il problema principale con la modalità a finestra singola riguarda la gestione delle sessioni di The GIMP. Il commit dovrebbe autorizzare all’avvio del programma come Single Window. Perché The GIMP 2.8 possa arrivare prima dell’8 dicembre di quest’anno, ciò non è ancora sufficiente: ci sono altre funzioni che richiedono correzioni.
Ad esempio, The GIMP 2.8 supporterà il raggruppamento dei livelli come già Adobe Photoshop e la formattazione del testo in linea. Un’altra feature prevista, e integrata nella versione di sviluppo per The GIMP, è l’esportazione dei documenti in PDF. Nonostante i progressi è difficile pensare a un rilascio prima del prossimo autunno.
Via | Libre Graphics World
Cossa è un plugin sperimentale per gEdit, l’editor predefinito di GNOME, realizzato da Carlos Garnacho per aiutare nella creazione di temi in Gtk+ utilizzando i CSS. Uno strumento importante per arricchire GNOME 3/Shell di temi diversi da quello predefinito, cioè Adwaita, sfruttando una caratteristica già presente nelle librerie Qt.
La caratteristica più interessante di gEdit-Cossa è sicuramente la possibilità di visualizzare un’anteprima dei widget in Gtk+3 per verificare l’avanzamento nella costruzione di un tema. Non aspettatevi qualcosa d’eccezionale, perché lo sviluppo di Cossa è ancora in una fase preliminare. Ad ogni modo, è un ottimo punto di partenza.
Garnacho ha preparato un video per dimostrare il funzionamento di Cossa su gEdit: è in formato WebM e non sembra esistere una versione su YouTube, ecc. quindi dev’essere scaricato. Cossa supporta una serie di sample che possono essere realizzati da terzi seguendo le linee guida: in questo caso però è necessario l’utilizzo di Glade.
Via | Libre Graphics World

WebApp è un framework in PyWebKitGtk per creare applicazioni orientate al desktop sfruttando le potenzialità di node.JS, il server di V8/JavaScript. Concepito da Tim Caswell (uno sviluppatore di HP per webOS), si propone inoltre d’offrire una GUI in HTML5 e CSS3 per i server di node.JS. Caswell è anche l’autore di node-gir su GNOME.
Il codice di WebApp è ospitato su GitHub e il primo commit ha appena ventiquattr’ore. C’è ancora molto da realizzare, tuttavia il progetto è già interessante: particolarmente adatto allo sviluppo su Linux con GNOME, per le sue caratteristiche WebApp può essere portato su qualsiasi piattaforma. L’utilizzo di WebKit non è vincolante.
Il concetto alla base di WebApp non è molto diverso da quello di Prism, il progetto di Mozilla Labs per separare le applicazioni web dal browser. Chiunque conosca HTML, CSS (e JavaScript) potrà sfruttare WebApp per fare altrettanto, via node.JS. La sfida è quella di trovare una collocazione al framework: le alternative si sprecano.
Via | ReadWriteWeb