Ciò nonostante, le richieste di un vero e proprio repository per Ubuntu a 64bit (parallelo a quello per i386) da parte del popolo di utilizzatori di architetture AMD-64, non è mai cessato e visto che nessuno si faceva avanti con un proprio spazio, ho accettato la collaborazione di Bernardo Bandos che da oggi in poi mi invierà i pacchetti di Compiz Fusion compilati per i processori a 64bit che io inserirò nel nuovo repository eyecandy per amd64!

Per aggiungere il repository alla vostra lista, editate – con permessi di amministrazione (sudo) – il file /etc/apt/sources.list, aggiungendovi quanto segue:

# Treviño’s Ubuntu Deisty EyeCandy Repository (GPG key: 81836EBF)
# Many eyecandy 3D apps: Beryl, Compiz, Fusion, AWN and kiba-dock
# built by jbs using latest available (working) sources from git/svn/cvs…
deb http://download.tuxfamily.org/3v1deb feisty eyecandy-amd64
deb-src http://download.tuxfamily.org/3v1deb feisty eyecandy-amd64

Quindi, date la fiducia alla mia chiave GPG pubblica con:

wget http://download.tuxfamily.org/3v1deb/DD800CD9.gpg -O- | sudo apt-key add -

Una volta fatto questo, per installare il tutto (e correggere eventuali problemi) valgono le stesse identiche indicazioni date per Compiz, CompizConfig e Compiz Fusion per i386.

Per ulteriori informazioni sull’installazione e l’ottimizzazione di Compiz Fusion, consultate il wiki italiano di Ubuntu che ho aggiornato anche con questi ultimi dettagli.

Mi è quindi sembrato ovvio rivolgere questa chiamata ai miei amati lettori ed in generale a chiunque voglia aiutare questo nuovo progetto ed abbia una sufficiente conoscenza dell’inglese (e di Compiz)…
Già poche persone volenterose dovrebbero essere in grado di rendere questo lavoro piuttosto rapido ma sopratutto efficace. Quindi collaborate!

Per quanti di voi si fossero avvicinati solo ora alla traduzione di software in ambienti liberi, ci sono degli strumenti ormai considerati standard che fanno capo a gettext rendendo questo processo molto semplice ed intuitivo (oltre che assistito) sia per gli sviluppatori che per i traduttori.
Dal vostro/nostro punto di vista (di traduttore, ndr) vi basterà usare tool come kbabel (se utenti KDE), gtranslator (se utenti GNOME), poEdit (se indipendenti) o un semplice editor di testo (se siete utenti duri e puri) per modificare il file *.po che di fatto risulta essere il nostro dizionario particolare (maggiori informazioni – sezione italiana del Translator Project).

Ora che vi ho elencato un po’ di risorse per modificare i file PO, guardiamo come ottenere e di lavorare sul file di traduzione italiano di Compiz Fusion… Per farlo ci sono due modi:

1. Scaricate e salvate il file it.po (il link punta sempre all’ultima versione) e iniziate a tradurlo con il tool che preferite, quindi salvate tutto ed inviatemi il file it.po risultante dal vostro lavoro.
   Riscaricate il file ogni volta che ci rilavorate per evitare di perdervi nuove traduzioni…

2. Usando il GIT, date i seguenti comandi:
         git-clone git://anongit.opencompositing.org/fusion/i18n
   Quindi traducete usando il vostro tool preferito (con cui dovrete aprire il file in i18n/po/it.po), quindi eseguite (dentro alla cartella i18n):
         git-diff-files -p > /tmp/it-po.patch
   Speditemi il file /tmp/it-po.patch e nel caso vogliate ritradurre date il comando sotto per aggiornare i files (dentro alla cartella i18n):
         git-diff-files -p | patch -Rp1 && git-pull

3. Installare Gobby, accedere al server obby.opencompositing.org porta 6523, la password è cfteam e traducete direttamente online editando il file it.po!

Siccome io e pochi altri abbiamo la possibilità di modificare il repository git i18n di Fusion, e non essendo stata creata ancora né una mailing-list né un vero e proprio gruppo di lavoro per le traduzioni, l’unico modo per rendere effettivo quanto avete italianizzato – come già detto – è quello di inviarmi il vostro it.po (o la patch generata) affinché io inserisca tutto in git…

Sperando che si uniscano quante più persone possibili a questo appello, prego chiunque ci lavori sopra, di non tradurre subito la prima stringa disponibile (per evitare di fare il lavoro doppio), ma di andare un po’ a caso . Magari potreste inserire qui tra i commenti quanto state facendo così da evitare inutili sovrapposizioni.
Resta comunque il fatto che prima mi inviate il file tradotto, e prima io posso inserirlo in git così da facilitare il lavoro di tutti.

A presto (attendendo i vostri it.po) ^_^… 

Hanno contribuito (fin’ora):

• Matteo Suppo (Triex)
• Danilo Saruis (DDany)
• Fabio Fiorentini (Ahren / FaBBio)
• Andrea De Iacovo (Firstbit)
• Emiliano Perulli
• Milo Casagrande

Da qualche settimana il maintainer ufficiale della traduzione italiana è Milo Casagrande, fate riferimento a lui per ogni cosa inerente l’i18n di Compiz e Compiz Fusion.

Il maggior problema di Compiz Fusion è il fatto che non vengono distribuite delle cartelle debian, di default che consentono la realizzazione dei pacchetti, per tanto (com era già avvenuto anche per alcune parti di Beryl e come succede quasi sempre per gli altri pacchetti che produco) le ho dovute fare io, praticamente da 0…
Avendo ricevuto l’accesso in scrittura al GIT di OpenCompositing qualche settimana fa, ho deciso che il nuovo sistema sarebbe stato molto più git-based.

Con un po’ di ritardo, stasera ho inserito in GIT tutte le cartelle debian necessarie alla creazione di pacchetti .deb, quindi dopo diversi aggiornamenti, ho inserito anche il nuovo makefusiondebs che vi permetterà di compilare e pachettizzare tutto!

Le modifiche rispetto alla versione precedente sono:

• Autoupdate (lo script si auto-aggiorna all’avvio)
• Supporto ad un file di configurazione (makefusiondebs-options)
• Supporto per le patch debian (sistema quilt)
• Controllo dell’ABIVERSION dei plugin (permette la ricompilazione automatica)
• La versione di base ora viene letta anche dal configure.ac
• Supporto per il prefisso delle versioni debian (#:versione)
• Corretta la rimozione dei suffissi debian alla versione
• Possibilità di definire il nome delle cartelle in cui salvare i dati
• Spostamento dei vecchi deb basato anche sul pacchetto sorgente
• Le cartelle debian utente, ora hanno priorità su quelle scaricate
• Codice ripulito
• Altre correzioni sparse che non ricordo

Per avere tutto questo, dopo che avete ripulito il vostro sistema dalle installazioni di compiz in /usr/local (soprattutto rimuovendo i file /usr/local/lib/pkgconfig/compiz*.pc), vi basterà dare i seguenti comandi:

A questo punto lo script tenterà prima di aggiornare sé stesso (ed in caso positivo di riavviarsi), se non impostato diversamente (vedi sotto), e poi scaricare (o aggiornare) tutte le sezioni del GIT definiti (che comprendono sia compiz-fusion-debian che compiz-wrapper – tra l’altro quest’ultimo è stato integrato in questi giorni proprio nei pacchetti di Ubuntu Gutsy!!) nelle opzioni…

Ho parlato di opzioni, sì, perché essendo l’autoaggiornamento basato su GIT, per evitare problemi col passare del tempo, ho deciso di dare la possibilità di definire le proprie impostazioni in un file parallelo, impostato di default a makefusiondebs-options, che potrete editare (mantenendo la sintassi bash) per personalizzare l’impacchettamento (piuttosto che toccando lo script stesso, per cui semmai inviatemi delle patch, ma che è meglio non modificare direttamente!).

Infine, un accenno ai parametri accettati dallo script:

Adesso se non potete o non volete usare i miei deb di Compiz, sarà possibile e molto facile creare pacchetti anche per tutte le distribuzioni (basate su debian) e tutte le architetture; se vi dovesse servire hosting per i vostri pacchetti – per un eventuale repository – contattatemi pure! 

Maggiori informazioni le troverete sicuramente in questo thread di OpenCompositing.

Bye ^_^ 

E invece… Beh, finalmente quei ragazzacci si sono messi daccordo ed hanno annunciato il nuovo nome in Compiz Fusion! Personalmente non mi dispiace, ma considerando quanto l’abbiamo atteso mi andava bene (quasi) qualsiasi cosa…

Ma veniamo al dunque, come promesso, non appena ci sarebbe stato il nuovo nome, i pacchetti sarebbero finiti nel repository ed infatti dopo aver messo il mio repostory Compiz-GIT e (opzionale) CompizConfig per installare i plugin che una volta erano di beryl e che adesso saranno di fusion, date il seguente comando:

sudo apt-get install compiz-fusion-*

Con il comando indicato verranno installati (ad oggi) i seguenti pacchetti:

• compiz-fusion-plugins-main – contiene i pacchetti sviluppati attivamente
• compiz-fusion-plugins-extra – contiene i pacchetti di minore importanza (come funzionalità)
• compiz-fusion-plugins-unsupported – contiene i pacchetti fatti (in passato) da autori esterni agli sviluppatori ufficiali e quindi non più sviluppati attivamente.
• compiz-fusion-plugins-unofficial – contiene i pacchetti non ufficiali e pertanto non supportati

Per adesso i plugin disponibili sono: animation, expo, imgjpeg, neg, opacify, put, resizeinfo, ring, scaleaddon, snap, text, thumbnail, vpswitch, wall, winrules, addhelper, bench, crashhandler, cubereflex, extrawm, fadedesktop, firepaint, group, mblur, reflex, showdesktop, splash, trailfocus, fakeargb, snow, tile.
Presto ne arriveranno anche altri, come widget, mousegesture, flash, screensaver (presenti ora nel pacchetto unofficial)…
Mentre vi consiglio di vedere questo video per godervi tutte le funzionalità.

Per gli sviluppi futuri e ulteriori news (di poco conto), vi consiglio di seguire questo thread "ufficiale".

Nel frattempo, se ci sapete fare con inkscape, e pennelli virtuali, potete partecipare all’Artwork Contest che sta già sta dando i suoi frutti come avrete visto in cima a questo post .

Con un certo ritardo (si sa, DavidR non è per i workaround… ) fu stravolto il sistema utilizzato  fin dagli esordi, inserendo la possibilità di usare plugin diversi per il salvataggio delle opzioni e Mike mikedee Dransfield creò un plugin "ini" che permette il salvataggio della configurazione in dei files (ciascuno per plugin) in ~/.compiz/options. Tuttavia, il ritardo dell’aggiornamento rispetto a Beryl che già aveva i suoi configuratori ed il sistema poco friendly di gestione non resero questo cambiamento troppo apprezzato…

Tutto il resto è storia recente, con il porting da libberylsettings (il fiore all’occhiello di Beryl) a libccs adesso rinominata in libcompizconfig di cui ho spiegato il suo funzionamento in questo articolo che è fondamentalmente sempre valido a parte il fatto che la libreria ha cambiato nome e che adesso il backend gconf usa gli stessi parametri del plugin standard di compiz (per il plugin ini verrà fatta la stessa cosa presto).

Nonostante i flames che ci sono stati nella Mailing list di CompComm riguardo l’approccio usato da questo sistema (alcuni validi, altri un po’ meno) portati avanti più che altro da mikedee e RYX (entrambi "ex" compiz-extra), la discussione è proseguita con un ritmo serrato e attualmente pare essersi placata sia perché si è deciso di mantenere una linea che rimanga sempre fedele ai plugin standard di configurazione di Compiz, sia perché fino ad oggi non esiste sistema migliore che permetta sia la configurazione, che la gestione dei conflitti sia in modalità online, che offline (ossia, con sia con compiz avviato che no).

Andiamo quindi ad installare CompizConfig; prerequisito a tutto ciò è l’installazione di Compiz-git dal mio repostory eyecandy (come era stato indicato anche tra i commenti del primpo post su CompComm), dopo di che vi basterà fare:

sudo apt-get install compizconfig-settings-manager

Questo, fondamentalmente, farà tutto il necessario per avere le librerie libcompizconfig, il plugin ccp (che funge da tramite per compiz) ed il configuratore CompizConfig Settings Manager (e relative librerie in python), tuttavia sappiate che per aver un sistema funzionante usando la configuazione di CompizConfig, vi basterebbe il solo pacchetto compizconfig-plugin libcompizconfig0 (ma ovviamente sareste senza interfacce).
Altri pacchetti che definirei opzionali, sono:

libcompizconfig-backend-gconf    # backend per salvare i dati attraverso gconf (GNOME)
libcompizconfig-backend-kconfig  # backend per salvare i dati attraverso kconfig (KDE)
python-compizconfig              # bindings in python per l’accesso a libcompizconfig
compizconfig-settings-legacy     # settings manager "obsoleto" scritto in C e GTK+

Per usare compiz con questo sistema di configurazione, se usate i miei pacchetti o il mio wrapper (per come è stato impostato quest’ultimo), vi basta dare il classico comando

compiz –replace                 # corrisponde a dare ‘compiz –replace ccp’

Presupponendo che avrete installato il settings manager principale, ecco cosa vi apparirà lanciando ccsm:

CompizConfig Settings Manager – Compiz Configurator

Ci tengo a sottolineare, di nuovo, che tutto questo è indipendente dall’uso o meno dei plugin di Compiz Fusion (ex CompComm).

A presto! 

Siccome, come è ben noto, David Raveman (DavidR) e gli sviluppatori che gli sono più vicini sono sempre molto cauti nel modificare il codice del core e dei plugin di base, posso dirvi senza problemi che queste build, seppur siano compilate con codice in fase di sviluppo, sono e (presumo) saranno sempre stabili e funzionanti.

Per aggiungere il repository alla vostra lista, editate – con permessi di amministrazione (sudo) – il file /etc/apt/sources.list, aggiungendovi quanto segue [EDIT qua per AMD-64]:

# Treviño’s Ubuntu Deisty EyeCandy Repository (GPG key: 81836EBF)
# Many eyecandy 3D apps: Beryl, Compiz, Fusion, AWN and kiba-dock
# built using latest available (working) sources from git/svn/cvs…
deb http://download.tuxfamily.org/3v1deb feisty eyecandy
deb-src http://download.tuxfamily.org/3v1deb feisty eyecandy

 Se non l’avete già fatto, date la fiducia alla mia chiave GPG pubblica con:

wget http://download.tuxfamily.org/3v1deb/DD800CD9.gpg -O- | sudo apt-key add -

Quindi potete aggiornare il vostro sistema stando attenti che i pacchetti compiz, compiz-core, compiz-plugins e libdecoration0 (e relativi) vengano aggiornati/installati (ci sta che la prima volta ci voglia un sudo apt-get dist-upgrade).
Per gli utenti GNOME ricordo di installare anche il pacchetto compiz-gnome, mentre per quelli KDE il pacchetto compiz-kde; gli altri (Xfce & co.), invece dovranno installare un decorator alternativo (come emerald) se non vogliono installarsi dipendenze collegate ad altri desktop (in attesa che la mia patch venga accettata ).

A questo punto non vi resta che avviare Compiz, e nella maggior parte dei casi il basterà il comando (che potrete aggiungere tra i programmi da avviare all’inizio della sessione):

compiz –replace

Tuttavia, per poter avviare Compiz correttamente in qualsiasi configurazione hardware/software supportata ho inserito un wrapper (basato principalmente sul codice del compiz-manager di Kristian Lyngstøl) in /usr/bin/compiz che di fatto esegue il binario vero e proprio (/usr/bin/compiz.real) con le impostazioni più adatte alla vostra situazione. Questo script, nominato Compiz-Wrapper (che è disponibile nel git di opencompositing.org cui ho avuto accesso qualche giorno fa) oltre a quanto fa in automatico, permette sia di passare i parametri "standard" di Compiz (che ottenete con compiz –help), sia alcune operazioni avanzate che potete vedere usando il comando

compiz -h

Ulteriori esempi del suo uso li potete trovare in questo thread; è tutto piuttosto semplice per l’uso normale, ma permette anche operazioni più avanzate …

Per quanto riguarda la configurazione di Compiz, installando solo quanto sopra indicato (ossia solo pacchetti provenienti dagli sviluppatori di freedesktop.org) e lanciando compiz con il "comando di base", vi consentirà di usare la piattaforma gconf a quanti hanno installato compiz-gnome (sempre se non definite altro da riga di comando…), mentre semplici files di testo (usando plugin ini) per tutti gli altri e tutto questo non è sicuramente il massimo dal punto di vista della configurabilità da parte dell’utente (entrambi i sistemi sono tutt’altro che friendly da settare), ma per fortuna c’è altro…

Notate che a volte, le vostre vecchie configurazioni o vecchi plugin salvati nel profilo in $HOME possono dare fastidio, quindi eseguite i comandi seguenti per le operazioni indicate a fianco:

In questo post non ho voluto menzionare in modo esplicito sistemi che, suppongo, diventeranno lo standard per configurare Compiz, ma siccome per adesso non fanno parte del progetto ufficiale (e penso rimarranno sempre un’ala esterna) ho preferito indicare qui solo come ottenere la vostra copia "pura" di compiz

PS: Se avete qualsiasi problema di avvio di Compiz, incollatemi, col pastebin, l’output restituito da compiz –replace -v

In questi mesi di sviluppo, ci sono state ovviamente molte modifiche che seppur non siano ancora state raccolte in una prima release di preview (e, ripeto, non ci sia ancora un nome), sono ormai usabili da diverse settimane, e queste includono, oltre al porting di quelli preesistenti, alcuni nuovi plugin e, come avrete capito dal post precedente, un nuovo sistema di configurazione (ben più comodo di gconf o dei file ini ufficialmente supportati da compiz).

Ma partiamo con ordine: il Nome. Purtroppo, come molte volte capita nel mondo FOSS, spesso ci si fa la “guerra” per le cavolate, ed il nome da dare al progetto di OpenCompositing.org pare esserne proprio un esempio. Ad ogni modo dopo aver rotto le scatole per settimane agli sviluppatori presenti nel canale #opencompositing-dev (freenode), finalmente siamo giunti a questo thread, in cui si spera di giungere finalmente ad una soluzione (che come capirete dopo, non è poi così ininfluente…). CompComm onestamente non mi pare un gran nome, meglio CoCo, ma anche altri nomi come Coral che venne proposto qualche mese fa, non sono male…
Insomma, prego anche a voi di partecipare alla discussione in modo produttivo!

Ovviamente i nostri amici sviluppatori, dopo aver reso funzionanti i plugin di Beryl su Compiz (anche grazie al lavoro di compiz-extra che ha pensato ad aggiornare i propri), non hanno perso tempo a creare Nuovi plugin, alcuni utili, altri un “po’” meno:

• firepaint: quello che avrete visto in cima a questo post; sicuramente utilissimo! (volete mettere che effetto fa scrivere «Non Toccare» col fuoco?!)
• resizeinfo: mostra le dimensioni attuali di una finestra durante il suo ridimensionamento come fa metacity, questo direi che è abbastanza comodo e ne potete vedere un esempio.
• compiz-scheme: un plugin molto potente che permette di programmare il nostro composite manager definendo diverse azioni in base ad uno script definito con una sintassi particolare [ancora in fase di sviluppo]
• sreencasting: permette di fare dei video dei vostri desktop 3d in modo più semplice (simile a beryl-vidcap nell’idea, ma diverso nell’implementazione visto che non usa più seom) [ancora in fase di sviluppo].

Infine, passiamo alla vera chicca prodotta in questo periodo dai ragazzi di OpenCompositing: CCS! Come si può “intuire” CCS è un acronimo per «Compiz Configuration System» e più o meno deriva da quanto era stato creato per beryl con libberylsettings, ossia un sistema che permetta di configurare compiz in modo semplice usando dei sistemi di salvataggio diversi in base all’ambiente utilizzato.

In pratica, Compiz è strutturato in modo tale da usare i plugin quasi per tutto, compresa la sua configurazione; possono essere scritti plugin per impostare il composite manager usando qualsiasi sistema di configurazione esistente, ma allo stato attuale esiste solo il supporto per gconf e per dei file di testo (ini) per cui l’unico modo di configurare il tutto con un tool "punta-e-clicca" è quello di usare gconf-editor che oltre ad essere marcatamente per GNOME, non è sicuramente il massimo come intuitività e comodità d’uso (esistono anche altri software, ma di fatto sfruttano gconf per leggere e scrivere le opzioni, e non dialogando direttamente con i plugin non si "auto-aggiornano").
È stato quindi creato un nuovo plugin (ccp – Compiz Configuration Plugin) che ha il compito di fare da “mediatore” tra compiz ed una nuova libreria, libccs, che compiz chiamerà per leggere le impostazioni definite dall’utente, mentre dei tool esterni la utilizzeranno sia per leggere i parmetri definibili di compiz (e quindi per "disegnarsi"), sia per impostare compiz stesso. Sarà quindi libccs che penserà a scrivere e leggere le impostazioni usando il backend scelto/installato (per adesso sono supportati sia i file ini, che i file di configurazione di KDE, che gconf); un primo esempio dell’uso di libccs l’avrete visto nel primo “configuratore” sviluppato in C (e molto simile al primo beryl-settings) per compiz + ccp: ccs-settings

Anche in questo caso (come per beryl) è stato creato un binding in python per libccs, così che sia possibile scrivere applicazioni python che abbiano accesso a tale libreria e da ciò, come era prevedibile, è nato un nuovo tool (sviluppato sopratutto da QuinnStorm) che si basa sia su beryl-settings-manager (come codice) che sull’ormai obsoleto ma tanto apprezzato Compiz-Settings (come interfaccia, a sua volta basata sullo GNOME Control Center); il suo nome è Compiz Configuration System Manager, vale a dire ccsm:

Mi pare un buon lavoro, no?!

Anche se fondamentalmente, dal punto di vista dell’utente si tratta solo di lanciare "compiz –replace ccp" invece che "compiz –replace gconf" (o ini), il sistema è abbastanza complesso ma allo stesso tempo potente, mi pareva quindi giusto spiegarlo un pochino…
È sottinteso in questo discorso, che se uno vorrà continuare ad usare il sistema standard di compiz "puro e duro" (e mi immagino già chi lo farà ), ovviamente dovrà continuare ad usare il precedente plugin di configurazione che potrà comunque convivere con quello fornito da CompComm (basta lanciare quello prescelto all’avvio di compiz). Per tanto, CompComm è un Add-on per Compiz, non più una MOD/Patch.

Ad ogni modo, anche se questo sistema lo apprezzo per molti versi (sia a livello di implementazione che di usabilità), tuttavia secondo me è stato commesso un errore (ovviamente riparabile, s’intende… E l’ho già detto anche agli sviluppatori) nel non mantenere questo sistema compatibile con quelli attualmente presenti in Compiz: ini e gconf; voglio dire, seppur anche questo sistema salvi le impostazioni in entrambi i supporti, usa delle variabili e dei metodi diversi, quindi risulta impossibile usare i settaggi passando da un sistema di configurazione all’altro…

Aggiungo poi [EDIT del 28-05-2007, ore 20:15] che, oltre ai vari script per compilare ed avviare Compiz con i giusti parametri, è in cantiere anche una sorta di beryl-manager, ossia un tool che si avvia nella tray del sistema e che permette di avviare e configurare al volo Compiz; attualmente il nome (provvisorio?) è Compiz Icon ed è stato inserito oggi in GIT); ecco a voi uno screenshot della situazione attuale, mentre questo è il thread di riferimento.

Se volete provare tutto questo, già nelle vostre ubuntu-box potete usare i pacchetti DI PROVA che ho creato in questi giorni mettendoli in un archivio (in attesa di un repository) disponibile su OpenCompositing; usatelo solo se sapete quello che fate, visto che è tutto ancora in produzione…
Sappiate, infatti, che tutto questo verrà presto inserito (appena si avrà un nome ufficiale – ecco che a qualcosa serve), insieme a compiz-git (che in realtà potrei già inserire…), nel mio repository eyecandy .

Ciao!
 

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à

Il portale fa parte della famiglia di kde-look.org & company, quindi non si tratta di una vera e propria novità visto che già da tempo nei siti di questo network erano presenti dei materiali per Beryl, ma adesso è stato creato un sito a se stante per raccogliere senza tanta confusione tra i DE e con delle caregorie specifiche le personalizzazioni per il gioiellino.
Mi è sembrato quindi importante farvi partecipi di questo nuovo progetto che renderà più semplice trovare e pubblicare risorse personalizzate per Beryl senza doversi mettere a lurkare centinaia di thread nei vari forum.

Per spargere la voce, vi prego di votare la news su digg.

Bye!

Comunque sia, ormai ce la dovevo fare e ce l’ho fatta (ovviamente), ricompilandomi Xorg, Mesa e altre librerie parallele (seguendo quanto ho scritto in questo post). Avevo iniziato a lavorare su Xorg e mesa git circa l’8 Febbraio come potete leggere in questo bug, ma ho raggiunto il successo solo il giorno successivo; in seguito ho usato Xorg e Mesa pacchettizzato in versioni "standard" fino a ieri quando mi sono messo in tesa di concedere questo piccolo sfizio anche agli altri utenti aprendo un repository. Per far ciò ho quindi ricompilato tutti i pacchetti relativi a xorg importati da feisty, ovviamente avvalendomi di alcuni miei script  che ho scritto al volo per automatizzare il tutto permettendomi di ottenere il tutto in circa 5 ore di compilazione!

A questo punto, siete pronti per aggiornare la vostra Ubuntu-box!

Fatta la “proverbiale prefazione” mi preme sottolineare già in apertura che quanto è indicato qui sotto è consigliato solo per gli UTENTI ESPERTI (ossia per coloro che sappiano gestire la propria macchina anche in caso di problemi col server X); dico questo non tanto perché quanto imparerete è di difficile attuazione (anzi dei due proprio perché è semplicissimo), ma perché nonostante ho feedback positivi da chi ha provato questo nuovo server X, non posso garantirvi il funzionamento su tutte le configurazioni.

Ritengo inoltre l’aggiornamento utile fondamentalmente per chi utilizza normali applicazioni 3D oltre che per chi usa un Composite Manager, ma in questo caso è caldamente consigliato l’aggiornamento solo se utilizzate AiGLX visto che non ho testato assolutamente Xgl sopra questo server (Aldolat ci è comunque riuscito).

Vi annuncio inoltre, che ho studiato le versioni dei programmi che andrete ad aggiornare in modo tale che non vadano a superare mai la versione presente in feisty, così che l’aggiornamento risulti assolutamente innocuo per gli sviluppi futuri della vostra macchina. Spero di aver fatto tutto correttamente, ad ogni modo i miei pacchetti funzioneranno anche in feisty quindi il male dovrebbe essere minore anche in caso abbia commesso qualche disattenzione.

Detto questo spero che la schiera di utenti che ha deciso di seguirmi abbia ancora una sua «consistenza», ad ogni modo ecco cosa otterrete con l’aggiornamento:

• Migliorato il funzionamento ed il supporto di AiGLX
• Migliorato il supporto a Compiz e Beryl
• Incrementate le performances 3D usando i driver open source (Intel e ATi sopra tutti)
• Eliminato il freezing durante il VT-switching su AiGLX
• Eliminati i problemi con il ripristino in seguito ad un ibernazione (legato a quanto sopra)
• Mhmhm… Tutti gli altri vantaggi di XOrg 7.2 e Mesa 6.5.2

Ovvia, ora che avete un po’ di bava alla bocca (non è vero, però…) possiamo iniziare con l’aggiornamento. I passaggi sono tutti molto semplici, fondamentalmente dovrete aprire il vostro sources.list (vale a dire sudo gedit /etc/apt/sources.list) ed aggiungervi il seguente repository:

# Treviño’s Ubuntu edgy Xorg-7.2 Repository (GPG key: 81836EBF – DD800CD9)
deb http://download.tuxfamily.org/3v1deb edgy xorg-7.2

Adesso, ne viene che dovrete aggiornare il vostro database di apt con sudo apt-get update e quindi di scaricare ed installare gli aggiornamenti, per farlo vi consiglio di usare tool come synaptic o adept piuttosto che il più rude sudo apt-get upgrade per poter così controllare in modo più accurato quello che state facendo.

Una volta che avrete applicato gli aggiornamenti, prima di riavviare X, non ci dovrebbero essere operazioni da effettuare, fondamentalmente il file di configurazione /etc/X11/xorg.conf dovrebbe andar bene com’è, l’unica cosa se utilizzate EXA come AccelMethod, sappiate che è buggata e ci sono problemi col rendering del testo; vi consiglio quindi di usare XAA.
Se volete in qualche modo testare il funzionamento di quanto installato potete semplicemente dare il comando X -version e dovreste ottenere qualcosa del genere:

X Window System Version 7.2.0
Release Date: 22 January 2007
X Protocol Version 11, Revision 0, Release 7.2
Build Operating System: Linux Ubuntu
Current Operating System: Linux 3v1 2.6.20-6-generic #1 SMP Mon Feb 5 15:42:24 CET 2007 i686
Build Date: 23 January 2007
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Module Loader present

Questo non è comunque un test valido, semmai potreste provare a lanciare un nuovo server (direttamente dalla vostra sessione X) con un comando tipo X :2 & DISPLAY=:2 xterm, così facendo potreste leggere gli eventuali errori direttamente dal terminale a cui lanciate il nuovo server, se il nuovo server (con un xterm), parte siete a posto, ad ogni modo potrete ritornare al server X di origine cambiando VT (con Ctrl+Alt+Fx dove x è o 7 o 4, cmq provateli un po’ tutti ).
Vi ammetto che io non ho praticato il test sopra in seguito al mio upgrade, quindi potrebbe anche non funzionare (ma non credo) se avete due server avviati di differenti versioni. Quello che è certo è che se lo faccio ora mi funziona correttamente.

Ad ogni modo senza star a fare troppe prove che spaccano il cervello, non posso che augurarvi buona fortuna e dirvi di fare un bel Ctrl+Alt+Backspace (o di chiudere la vostra sessione KDE/GNOME) per riavviare X!

Bene, spero sia andato tutto a posto
In caso contrario, invece se X non dovesse partire vi consiglio di guardare cosa c’è di errato nel log di Xorg magari usando il comando tipo grep EE /var/log/Xorg.0.log|less.

Se invece usate Beryl o Compiz ed avete problemi di cubo bianco con nVidia, dovrete reinstallare (rigenerando moduli del kernel e di xorg) i driver della vostra scheda video (magari usando Envy).

Se invece volete downgradare a Xorg 7.1 e Mesa 6.5.1+cvs (ossia gli standard di edgy); prima di tutto dovrete rimuovere il repository dalla sources.list, quindi dopo aver dato il classico sudo apt-get update dovrete avviare questo comando:

Eventualmente salvatevelo in un file così che si accessibile anche nel caso X non vi ripartisse (caso che cmq ritengo piuttosto improbabile)… 

Ovvia, mi pare d’aver detto tutto… A presto!

PS: Questo articolo si è liberamente basato sul post che ho pubblicato ieri su ubuntuforums.

• Le fanfare per Windows Vista (ZeusNews)
• Windows Vista, qualche consiglio d’acquisto (Il Disinformatico)

Qualunque sia la vostra opinione sulla cosa (commentate pure, eh!), questo articolo nasce per per un motivo solo "leggermente" collegato: la campagna Show us your "Wow"!
Nel sito msn, infatti si richiede agli utenti di condividere con gli altri il proprio momento di stupore, che appunto dovrebbe sucitare la scoperta di Vista, ma siccome a me l’ex codename Longhorn m’ha tutt’altro che stupito ho deciso di inviare al caro Bill il mio vero WOW.
Ve lo ripropongo:

(questo invece è il wow in tutta la sua forma)

LOL!
Tutto questo per dire, che il mio primo e vero «WoW» (informatico, ndr) l’ho sospirato più o meno un anno fa quando Xgl e Compiz fecero la loro prima comparsa al mondo con questi video di presentazione a Parigi e poi ancora con l’indimenticabile screencast del geniale David Raveman che mi fece rimanere a bocca aperta per diversi minuti; per non parlare delle mie prime ore passate a giocare (sì, il termine è giusto) con Kororaa.

Eh beh… Sì! Quello era un gran bel «wow» che all’epoca mi pareva quasi fantascienza pensando che necessitasse hardware recentissimo (e pensare che invece va con PC di 4-5 anni!) e che magari dovesse attendere molto prima di uscire al mondo… Ed invece, un anno dopo ci fanno passare per innovativo un sistema che ha solo effetti da poco che richiedono risorse esagerate che ci dovrebbe stupire vedendo un poco utile Flip3d che i ragazzi di Beryl e Compiz potrebbero realizzare in pochi giorni…

Tuttavia, tornando all’attualità per far le cose per bene ho inviato il tutto a “mamma” Microsoft, ed ecco che mi hanno risposto quei cattivoni:  

Oggetto: Non è possibile pubblicare il tuo Wow!

Grazie per il tuo interesse in Mostraci il tuo Wow. Sfortunatamente, la tua iscrizione non è stata accettata per questo sito web. La tua iscrizione non verrà pubblicata, e non sarà condivisa da Microsoft con nessun terzo.

Ops… E io che ci speravo…!  

PS: un altro «wow» vero che ho apprezzato è stato questo.

Vi parlerò di conky, un System Monitor minimale (quasi testuale direi) ma con un’estensibilità praticamente infinita.

Inanzitutto installiamolo sulla nostra debian (ubuntu e derivate varie) da root/sudo con apt-get install conky

Prima di avviarlo, configuriamolo in maniera single-user. Vale a dire copiamo il file di configurazione nella nostra home, così facendo:

zcat /usr/share/doc/conky-1.4.0-r1/conkyrc.sample.gz >> ~/.conkyrc #Sostituite 1.4.0-r1 con la vostra versione di Conky

Con questo comando abbiamo semplicemente decompresso il file di configurazione standard dalla directory di documentazione, e l’abbiamo inserito nella nostra home

Digitate adesso lanciate conky dal vostro terminale e comparirà sul vostro desktop la sua schermata, che mostrerà tutte le informazioni. Come modificarlo??? Eheh, ve l’avevo detto che è minimale. Editate il file ~/.conkyrc, troverete una serie di parametri abbastanza intuitivi di cui qui la spiegazione dettagliata.

E’ inutile dirvi che una volta modificata la configurazione, dovete riavviare conky….

Un aiutino posso però darvelo. Ad esempio:

Text alignment, other possible values are commented
alignment top_left
alignment top_right
alignment bottom_left
alignment bottom_right
alignment none

decommentate la riga che vi interessa riguardo la posizione di conky sul vostro desktop.

Gap between borders of screen and text
same thing as passing -x at command line

gap_x 12

gap_y 42

questi due invece sono i valori di coordinate di conky sul vostro desktop (il valore 0 dipende da dove avete allineato la finestra)

E così via; è presente l’intervallo di update, lo sfondo trasparente, il colore, e altri parametri. Infondo al file ~/.conkyrc troverete poi il template di conky.

Potete trovare alcuni template comprensivi di screenshot a questa pagina.
Eccovene qualcuno per darvi una idea:

Questi in particolare sono stati moddati con script particolari, che detto in breve, non fanno altro che popolare un file di testo che verrà poi letto da conky (info per xmms, gmail, wether forecast, ecc..).

Dilungarmi su questo sarebbe un po’ difficile, ma googlando un po’ troverete di sicuro guide esaurienti  

Nardin

Ecco uno dei miei due “best gift for Xmas” – “bei regali” del passato Natale, naturalmente in versione opensource. Questo post prende infatti frutto da uno precedente dell’ormai andato Natale 2006 arricchito di ulteriori informazioni e novità

Volevo presentare la nuova release, rilasciata pochi giorni or sono, del “gioiellino” Murrine (GTK2 Cairo Engine per Gnome), scritto dall’italianissimo Andrea "Cimi" Cimitan. Questo motore GTK per gnome mira a dare un tocco stile vetro di Murano (da qui appunto il nome «Murrine», plurale di «Murrina») al vostro desktop del piede nero garantendovi personalizzazioni e velocità senza paragoni.

Seppur si parli di un progetto ancora piuttosto recente, la nuova versione 0.40.1 risulta già molto matura; ecco la lista dei cambiamenti di Murrine (che mi ha trafugato Cimi stesso) e ora ufficiali:

Un po di screenshot:

(Murrine in Action! Click per ingrandire…) 

I cambiamenti sono effettivamente molti e si passa da radio e chechbox completamente riscritte in stile ubuntulooks, pur rimanendo sempre sulla base del vetro di Murano; nuovi stili del glaze per integrare meglio i temi di beryl; possibilità di scegliere la decorazione delle scrollbar (striped, orizontal striped, dots, handler – a mio avviso il cambiamento migliore) e inoltre un’ aggiunta di dots per quanto riguarda le colonne/tabelle nei form delle GTK.

Lo strumento per far questo è il cosidetto Murrine Configurator, installabile, dopo averlo scaricato e scompattato, tramite un semplice sudo ./install.sh oppure ancora più facilmente usando il .deb dei repository di 3v1ñ0 (il pacchetto si chiama murrine-configurator). È quindi possibile avviarlo dal Pannello di Gnome, tramite Sistema -> Preferenze -> Configuratore di Murrine (vedi l’icona a lato) ed iniziare a personalizzare i vostri temi con le opzioni descritte precedentemente.

Inoltre, per finire in bellezza, ecco gli ultimi aggiornamenti dal fronte “murrinoso”:

1. Murrine farà parte (finalmente) del repository Universe di Ubuntu 7.04 aka Feisty Fawn. E’ stata accetta infatti da poco per il fatto che sarà il tema ufficiale della distro UbuntuStudio, tema che strizzerà un pò l’occhio a tuttti voi dark là fuori.
2. Tra poco uscirà una nuova versione di Murrine che supporterà decisamente in maniera migliore i temi dark inserendo nel gtkrc l’opzione Hilight_Ratio e un valore che permette di sogliare l’ Higlihlight value del tema. (via Cimi )
3. Guardando avanti: che dire, sperare che i signori di gnome si sveglino e accettino Murrine, se non come default, almeno come tema/engine opzionale tra i vari Crux e Co.
   Gnome needs also designers not only coders!

Che dire un bel regalo per Natale, no (anche se in ritardo) ?!

iAc alias LizardKing