|  Normalmente, come avrete notato, seppur segua da vicinissimo le vicende dei desktop 3D (stando anche sempre a contatto con gli sviluppatori) non posto molte notizie che li riguardano, visto che di solito in poco tempo rimbalzano nella blogosfera, preferisco magari rendere disponibili queste novità a tutti in formato .deb  , ma ultimamente, dopo la fusione tra Compiz e Beryl tutto sembra essersi fermato… Ma ve lo dico subito, non è così!
Facendo un passo indietro e nel tentativo di rendere pieno il senso del titolo, facciamo una mini-storia fino ai tempi non lontani in cui Beryl era un progetto vivo: il mio primo composite manager è stato xcompmgr (che esiste già dal 2004) anche se a causa di problemi di supporto hardware l’esperienza finì molto brevemente; poi grazie all’avvento di Xgl, il serverone 3D, passai al primo composite con la "C" maiuscola: Compiz , ma - come molti sanno - dopo il rilascio del codice da parte di Novel, per diversi mesi il suo sviluppo sembrava essersi interrotto, fu così che in seno alla comunità Ubuntu, e ad opera di QuinnStorm, nacque Compiz-Quinn ossia una versione modificata di compiz che risolveva diversi problemi ed aggiungeva alcune funzionalità; la comunità si spostò quindi in massa a questa nuova versione patchata che poi col tempo assunse sempre più una sua fisionomia fino ad essere “costretta” al fork; magari più per incomprensioni che per motivi reali, però l’incapacità di parlarsi portò ad una divisione tra Compiz di freedesktop e Beryl; la mia scelta fu in beryl, anche perché nella sua fase iniziale la comunità era davvero parte integrante dello sviluppo come in pochi altri progetti; come ebbi a dire in altri post: «ti faceva sentire importante e vivo nello sviluppo».
Tuttavia, questa divisione ha dato origine a due cose: una positiva, l’altra meno… Ossia, il fork ha dato slancio al “gruppo” di freedesktop (= David Raveman) che ha riniziato a mettere le mani seriamente sul codice di compiz e, come altra conseguenza, sono nati anche i flame che tutti conosciamo e che se da una parte dimostrano che la comunità è viva più che mai, dall’altra ritengo che si siano spinti davvero troppo oltre.
Ad ogni modo, quando ormai i due progetti sembravano essere sempre più lontani tra di loro (a livello "ideologico", s’intende…), la ragionevolezza ha preso il sopravvento e si è deciso da una parte di aprirsi un po’ di più (compiz), mentre dall’altra si è rinunciato alla propria indipendenza ed a diverse righe di codice, magari ben condito di hack, ma quantomai funzionante e facile da gestire (beryl) per arrivare ad un progetto comune, sviluppato però da due reparti principali:
- Compiz, quello vero, ha il compito di progettare ed implementare il codice del core e di alcuni plugin di base che già garantiscono il perfetto funzionamento del composite manager (anche se limitato in funzionalità e facilità di configurazione); il tutto in un team abbastanza ristretto e composto dai migliori sviluppatori del campo capitanati da David Raveman.
- OpenCompositing / CompComm / CoCo / ??? (c’è già quasi tutto, tranne che un nome ufficiale) ha il compito di creare una comunità attiva nel supporto, la configurazione e lo sviluppo che riunisca gli sviluppatori (e gli utenti) più sfarfalloni di Beryl e Compiz-extra per produrre plugin aggiuntivi ed un sistema di installazione, avvio e configurazione a prova di niubbo usando però come base sempre e solo il core ufficiale di Compiz per cui questi tool sono solo un aggiunta tutt’altro che indispensabile.
Fin qui, niente di nuovo (a parte i nomi provvisori) visto che sostanzialmente ho riscritto quanto indicato nelle roadmap ormai da due mesi e passa, ma nel tempo che è trascorso dall’ultima release (assoluta) di Beryl e dall’ultima stabile di Compiz (la 0.3.6) ad oggi entrambi i progetti non sono stati con le mani in mano.
Sul lato di Compiz, ci sono stati diversi cambiamenti sostanziali al nucleo che seppur non cambino molto la vita degli utenti, senza star ad entrare in superflui tecnicismi, toccano molto l’approccio di programmazione visto che è stato modificato il sistema con cui sono definite le opzioni del core e dei plugin passando da un sistema hardcoded nei sorgenti in C ad uno che sfrutta dei files xml esterni (metadata) da cui vengono poi generate le opzioni con cui si dovranno interfacciare sia lo sviluppatore (per definire i comportamenti a livello di codice) che gli utenti (per impostare compiz, ovviamente tramite software di configurazione appositi). Ad esse si uniscono il già noto supporto per l’input redirection che Xorg 7.3 supporterà, l’aggiunta di alcune feature importate da beryl (più che altro sui plugin) altre al bugfixing di routine.
Modifiche quindi piuttosto importanti, ma appunto, non troppo appetibili (immagino) per la maggior parte della platea.
E sul lato della comunità di OpenCompositing (per ora chiamiamola CompComm), invece?
Beh… Si dice che un immagine valga più di molte parole, per ora, vi lascio a questa:
A presto, per altre brucianti novità 
 |
RSS/ATOM Feeds Aggregator
A pochi giorni dall’ 
