Hamster ha finalmente trovato la propria collocazione su GNOME Shell. L’applet per il calcolo del tempo da dedicare ai vari task tornerà installabile a partire da GNOME 3.2.0 come previsto dagli sviluppatori. Inaccessibile dall’uscita di GNOME Shell, è stata “riposizionata” sul pannello di GNOME: sposterà il calendario sulla destra.
Jānis Jansons aveva concepito un mockup di Hamster, trasformando l’applet in un’icona nella tray: gli sviluppatori di GNOME hanno optato per una soluzione diversa. Quando Hamster è attiva, il calendario (e quindi l’orologio) si sposta sulla destra per lasciarle spazio al centro. Chiudendola, il pannello ritorna all’aspetto normale.
In un primo momento, Hamster doveva essere posizionata direttamente sulla destra del monitor: l’opzione centrale è stata scelta a seguito di un breve sondaggio tra gli utenti. Hamster può essere installata come indicatore per Unity, grazie al progetto di Alberto Milone. Le modifiche all’applet sono, invece, opera di Jérôme Oufella.
Immagine | Toms Bauģis (via Flickr)
Esattamente una settimana fa abbiamo parlato del progetto di Alberto Milone per integrare Hamster, l’applet di GNOME2, in AppIndicator su Ubuntu con Unity. Il problema resta GNOME3, perché GNOME Shell non prevede le applet di GNOME Panel, compatibili fino a GNOME 2.32.1: una soluzione sarebbe quella di “spostare” Hamster nella tray.
È la soluzione di Jānis Jansons, che sta lavorando all’esperimento su Arch Linux. La transizione non è poi così semplice, perché gli stessi sviluppatori di Hamster hanno escluso un’integrazione del programma prima di GNOME 3.2… proprio per studiare il problema del pannello. Lo script di Jansons è una modifica di quello di Milone.
Aggiornando Arch Linux a GNOME3, lo script di Jansons è risultato corrotto: la strada per ottenere Hamster funzionante su GNOME 3/Shell è ancora lunga. Jansons ha predisposto un workaround (temporaneo) per l’avvio di Hamster, tuttavia pensa di riscrivere completamente lo script. Quanto prima, hamster-tray dovrebbe approdare su AUR.
Via | Hamster
Fluxbox è un window manager: ha sostituito Blackbox, col quale è retro-compatibile al 100%, quando quest’ultimo è stato abbandonato dagli sviluppatori (nel novembre del 2005). Mantenuto da cinque individui, Fluxbox non ha un ciclo di rilascio periodico. L’ultima versione, la 1.3.0, è stata pubblicata soltanto sabato in prima serata.
Poiché Fluxbox non è un desktop completo, può essere inserito tra le sessioni di GNOME e/o KDE. Supporta, con un’opportuna configurazione, il lancio delle applicazioni di entrambi. Trattandosi di un window manager non può invece funzionare contemporaneamente a Compiz o, KWin. Fluxbox 1.3 aggiunge il supporto al testo bidirezionale.
Purtroppo, Fluxbuntu (una distribuzione Ubuntu-based su Fluxbox) sembra essere stata abbandonata: era un modo semplice per ottenere un sistema col window manager come predefinito. Fluxbox è in uso su Sabayon, Slax e il LiveCD di GParted. Questa release è stata dedicata da Mathias Gumz alla figlia, Karo, nata il 6 novembre del 2010.
Via | Phoronix
Nel primo pomeriggio di ieri è stato predisposto un repository con BuildBot per il ciclo di sviluppo di LXDE. Gli snapshot dei progetti vengono generati automaticamente ai minuti :01, :05, :08, :12, :16, e :20 di ogni ora. Oltre al “core” di LXDE sono presenti componenti e applicazioni tra cui LXAppearance, e PCManFM di cui abbiamo avuto modo di parlare in passato. LXMusic fallisce, invece, la compilazione.
BuildBot è un sistema per l’auto-generazione cronologica degli snapshot di un dato progetto che può essere associato a diverse piattaforme DVCS. È diventato popolare come il sistema sfruttato da Google per la pubblicazione degli aggiornamenti ai binari di Chromium e sempre più sviluppatori decidono d’implementarlo. LDXE lo propone con un’interfaccia minimale, molto più essenziale di quella predisposta da Google.
Da BuildBot si possono reperire informazioni utili anche qualora, al posto dei binari, si voglia procedere alla compilazione personalizzata dei sorgenti. Per fare un esempio, LXDE utilizza GCC 4.4 e su BuildBot è possibile consultare una lista dei risultati relativi ai successi e ai fallimenti del compilatore. Il team di LXDE ha installato una versione obsoleta di BuildBot, cioè la 0.7.12 (l’ultima è la 0.8.1), su Python 2.6.
Via | LXDE
Martin Gräßlin è lo sviluppatore che si occupa del compositing di KWin: avevamo già accennato al suo lavoro su KDE SC 4.7. In questo caso, invece, KWin non è la sua preoccupazione principale. Un aspetto molto controverso nello sviluppo di Linux è la disomogeneità dei progetti che si muovono in parallelo per lo stesso obiettivo e la collaborazione è fondamentale.
La pensa così anche Gräßlin e proprio per questo ha deciso di scrivere alla mailing list di Compiz per proporre lo sviluppo di specifiche comuni. Un progetto apprezzabile, inoltrato anche ai colleghi di Plasma e KWin. Considerando il percorso di Compiz verso la prima versione stabile e il futuro (imminente?) di Mutter per GNOME uno standard sarebbe l’ideale.
La cooperazione tra i team di GNOME e KDE sancita dai vari summit procede in realtà molto lentamente. Ciò soprattutto a causa dell’estrema frammentazione dei progetti. Riunire le esperienze di chi lavora al compositing può essere una soluzione interessante per migliorare. Resta da capire se e come la proposta di Gräßlin avrà successo e quali conclusioni porterà.
Via | Phoronix
Gli sviluppatori di LXDE sono al lavoro anche mentre in Italia continua l’esodo estivo (per chi ha la fortuna di andare in villeggiatura). Nell’ultima settimana le modifiche apportate a LXAppearance lo hanno reso «il gestore di temi in Gtk+ più ricco» tra quelli che non dipendono da GNOME. La partnership con Canonical porterà i fix, i cui sorgenti sono già disponibili via SVN, direttamente in Lubuntu/Maverick da ottobre.
Le novità sono importanti perché soprattutto in distribuzioni come Ubuntu la dipendenza dei window manager in Gtk+ da GNOME appesantisce globalmente il sistema. Il team coreano di LXDE aveva cominciato a “svincolarsi” dal desktop environment maggiore con PCManFM privo di GVFS (lavoro ultimato solo pochi giorni fa). LXAppearance è il theme manager sostitutivo dell’equivalente per GNOME e farà a meno di GConf.
In termini più semplici non sarà necessario installare GConf su LXDE perché LXAppearance è ora pienamente integrato con OpenBox. Temi ed engine Gtk+ possono essere controllati da OBConf, riducendo le dipendenze d’installazione e lo spazio su disco. Nel panorama dei desktop “leggeri” lo sviluppo di LXDE si sta affermando come quello più laborioso e interessante. Grazie alla GSoC 2010 non mancheranno altre novità.
Via | LXDE
La dipendenza di LXDE da GNOME è sempre più limitata grazie ai progetti della GSoC 2010. Da quando HAL è stato deprecato la gestione dei dischi è deputata a DeviceKit, con cui GNOME interagisce attraverso GVFS. LXDE sta per rendersi indipendente dal file system virtuale di GNOME ottenendo la possibilità di gestire i volumi direttamente da UDisks.
Questa novità è importante perché LXDE è un desktop environment in Gtk, perciò molti dei suoi componenti richiedono l’installazione delle librerie di GNOME. Eliminare l’uso di GVFS nel dialogo coi volumi significa ridurre le dipendenze in comune con GNOME e di conseguenza lo spazio su disco e le risorse richiesti da PCManFM (il file manager di LXDE).
PCManFM si appoggia a LibFM, che deve passare da GVFS per amministrare i dischi da montare/smontare. Integrando il supporto a UDisks direttamente in LibFM si soddisfano le prerogative basilari di LXDE, un desktop environment leggero per sistemi datati o, dalle ridotte capacità. Quando disponibili gli aggiornamenti saranno nel repository Git di LXDE.
La storia dello sviluppo di Compiz ha conosciuto alti e bassi, fork e “ricongiungimenti” tra team antagonisti: come nei migliori film hollywoodiani in previsione della versione 1.0 – dalla quale ci separano altri mesi – si è giunti all’happy ending che ha riportato all’equilibrio degli esordi, ovvero niente più Beryl/Compiz-Fusion/ecc. e un solo core per tutti. Compiz, appunto… mentre GNOME inaugurerà Mutter.
Non proprio un tempismo eccezionale quello degli sviluppatori di Compiz, sebbene GNOME Shell possa essere disabilitato (e non soddisfa tutti gli utenti) e il compositing integrato nella futura versione di Metacity – di cui Mutter è il successore – offre feature più limitate. Elucubrazioni a parte, la versione 0.9 di Compiz che era prevista per il 2009 è in procinto di essere rilasciata — anche tramite un PPA.
Prima che ciò avvenga gli sviluppatori gradirebbero un feedback degli utenti teso a “tracciare” i bug presenti sulle varie configurazioni: è possibile usufruire di un comodo script che facilita la compilazione da terminale della versione Git per tutte le distribuzioni, quindi compilare un sondaggio (in verità piuttosto lungo e articolato) sulla propria esperienza. Uno strumento molto utile per aiutare lo sviluppo di Compiz.
Via | Phoronix
La stagione non suggerisce certo che l’estate sia imminente (non so da voi, ma qui continua ininterrottamente a nevicare) eppure LXDE – un desktop environment sempre più completo e apprezzato, benché molto leggero – sta già pensando alla prossima Summer of Code.
L’inizio delle attività previste, di cui è possibile consultare una bozza (anche in riferimento all’applicazione come studenti), è a cavallo dell’uscita di Lucid Lynx – sul quale approderà ufficialmente Lubuntu – ma i risultati saranno pubblicati soltanto a fine agosto.
In questa fase preparatoria è fondamentale prendere visione della timeline poiché i tempi non sono comunque così dilatati: il sito ufficiale della GSoC 2010 fornisce tutte le informazioni utili a chi intendesse approcciare anche per la prima volta il programma open source di Google.
Non è il primo desktop environment a effettuare questa scelta: LXDE ha deciso di passare a Git per la gestione del proprio codice sorgente e per “festeggiare” la transizione è stato pubblicato un intrigante video che dà corpo alla struttura dell’albero di sviluppo.
Curiosamente i repository di LXDE su Git sono ospitati da SourceForge, anziché da GitHub o soluzioni equivalenti: una scelta non convenzionale — dal momento che SourceForge offriva preferibilmente archivi basati su CVS o, SVN.
Il funzionamento del repository è spiegato tanto nel post già citato sul blog di LXDE, quanto nella guida standard di SourceForge a Git: il motivo principale del cambiamento – LXDE manteneva archivi Subversion, di cui restano disponibili tutti i log – è la maggiore velocità di Git.
Seguici
ossblog è un supplemento alla testata Blogo.it registrata presso il Tribunale di Milano n. 487/06, P. IVA 04699900967. Contatti, Chi siamo, Condizioni di utilizzo, Privacy.
© 2004-2012 Blogo.it, alcuni diritti riservati sotto licenza Creative Commons.
Per informazioni pubblicitarie e progetti speciali su Ossblog.it contattare la concessionaria esclusiva Populis Engage.
