That’s my blog… Life and Linux

Introducing Locally Integrated Menus to Unity 7

Hey Ubuntu folks¹!

This is the Unity desktop team and during the last months we focused, as always, in polishing and improving the user experience of our default window manager for the next upcoming LTS!
In fact, while in the last months most of the Canonical commitment to Ubuntu has been directed to the Touch form factors, the “classic” desktop has not been forgotten at all and, we’re still working hard on it, to give our users the best experience and to approach smoothly to the convergence vision that we’ll get with Unity 8.

Part of this work have been the spread improvements, the HighDPI support, the new decorations and tons of various bugs fixed; however with this important milestone coming we also wanted to finally propose a solution to fix the main UX bug we have in Unity since its very first release: the menus being hard to find or too far from their parent window.

In fact, having the applications menus in the top panel really worked very well in small screens but now, especially with HiDPI monitors getting more and more popular, the top panel could be really too far from the actual window location… The solution, that the UX designer JohnLea has defined are the Locally Integrated Menus (LIM).

Ubuntu Unity Integrated Menus

People might recall that also at 12.04 times we implemented a first prototype of LIM, however due to some very-hard-to-fix issues we had with core applications, we decided not to try to propose an half-working solution for an LTS.

So, almost 2 years have passed, but our intent to get this feature done was still strong, although this time we wanted to implement LIMs in the proper way, as Ubuntu quality standards deserve. In addition designers defined a new and improved revision of their work, proposing to show the menus inside the decorations themselves in horizontal mode (until we’ve room for them); so, continuing to save the precious vertical space and keeping the nice look of menu-less windows unchanged.

To be honest, we’d loved to land this way before, but the amount of technical work needed has not to be underestimated.
Being more precise, one of the blockers we had in 12.04 was our dependency on the legacy compiz decor plugin + gtk-window-decorator, that has worked “OK” in the last years but – a part from using deprecated technologies (gtk2 in primis) – it really would have made this concept impossible to realize.

So, the first step has been moving away from the old gtk2-based decorations and writing brand new decorations supporting Gtk3 CSS theming² inside Unity itself; this has been an huge work (including writing a brand-new widget system for handling compiz textures in a more natural way), but it gave us great benefits in the end such as much faster windows resizing , improved look, support for dynamic scaling (for both HighDPI and accessibility reasons).

Once we had this new layout where to place any widget quite easily, all took shape in few lines, we only had to handle the fact that now menus opens on mouse button release and only if the user doesn’t keep it pressed for too long³, while a slightly trickier part was to handle the case where we had a too small window to show menus in horizontal mode, and where we had to fallback to a dropdown menu.

LIM’s dropdown, shown if we have not enough space

As this is an LTS release, before setting this menu mode as the default we wanted to have some community feedback. For now, you have to enable it using the Unity Control Center Appearance panel, and let us know what you think!

Unity Control Center with Application Menu settings

Tweakers might be happy to know that there are also other settings you can use to adjust your LIM experience under the com.canonical.Unity.IntegratedMenus gsettings schema, that allows to define the pressure and movements thresholds, and to also enable double-click over the menus (to maximize the window, if you’re fast enough); However, while you can adjust the settings for now, we encourage to use the defaults as they are based on wide user testing and are coherent with our design guidelines.

After some words, I guess it’s time to see them in action, and upgrade your Ubuntu Trusty machine to enjoy them!


Youtube Video

[1] Hello Planet, I should also probably say! ;)
[2] We really encourage and support anyone who wants to update its theme to support Unity
[3] Maximum press time is configurable, but default values are based on design user testing

Welcome back on blog.3v1n0.net….

Me, behind UbuntuSalve gente! Oh, no ora si parla “inglese” via….

Hi there!
This is the first blog post here after soooo many years… Something like almost 7 years, really?!?

Oh, yes… You all thought that I was dead as a blogger I guess, and well mostly I am as my time for writing really went below 0 during this time, and then… Well as always I wanted to keep this thing updated following “my rules” of keeping the timeline in sync with actual events, but this failed everytime… And so, yeah here we are after so much time!

The main reason why I become unresponsive during these years was that instead of writing text, I moved to write code (for real) and I found it much more fun and useful for the people around me.

More importantly during this period my commitment with the Free Software  increased and I  joined or submitted patches to various projects such as Compiz, Openmoko, EFL (Enlightment Foundation Libraries), GNOME, and… Well how you might think from the pic, Ubuntu.

Ubuntu took a very important role in my life since about the last months of 2010, when Unity, was proposed as the new default desktop environment, I liked a lot the idea, but it was still a new baby with many missing features and bugs and so I decided to jump on the boat to give my help to make Unity the best desktop.
This involvement lead me to join to my first, beloved, UDS in Budapest where I met for the first time a lot of “ubuntu-dev-heroes”. Once back I continued contributing a lot, as I enjoyed so much that experience that I wanted to make it something more than just an hobby…
And well, long story short, I’m now working at Canonical for more than 2 years as a Software Engineer for the Unity Shell! I love this job and I think we’re doing great things, trying to make the Ubuntu vision happen in every form factor.

You might be able to read more about this experience on my Google+ page or looking at my opensource contributions at ohloh.

PS: But… Is still anyone reading? :)

TuxFeed.it – Un Planet per i Blog Italiani dedicati a Linux

TuxFeed LogoMentre il caldo e qualche blackout stanno mettendo a dura prova tanto me quanto le mie periferiche, mi è giunta la notizia della nascita di un progetto di cui sentivo la mancanza da tempo e che io stesso avrei voluto avviare se nessuno si fosse fatto avanti prima, vale a dire l’apertura di un Planet in cui aggregare i blog italiani dedicati a Linux!
Questo progetto ha preso forma grazie ad Alessandro Pagano e Leonardo Racanelli sotto il nome di TuxFeed e raccoglie già da adesso i feed dei blog dedicati al Pinguino più noti nel panorama italiano di cui mi vanto di far parte.

Se siete autori di un blog in cui si trattano anche argomenti legati a linux, potrete richiedere di essere aggiunti tra le fonti per aumentare la vostra visibilità.
Se invece siete semplici lettori da oggi avrete un metodo rapido ed efficiente per tenervi aggiornati su quanto avviene nella blogosfera linuxiana sottoscrivendo un solo feed.

Sperando che questo aggregatore cresca bene (magari con una struttura più simile ai veri planet) e ben popolato da blog di qualità vi lascio ad una sua visita più approfondita:

TuxFeed.it
Visita TuxFeed.it

Bye ;) 

Linux prende possesso della Camera dei Deputati

Tux alla Camera dei DeputatiDopo la migrazione del Parlamento Francesce a Linux (kubuntu, per la precisione), anche la Camera dei Deputatidopo aver accolto anche me, ai tempi della quarta liceo – ha scelto di far entrare "Il Pinguino" dentro al cuore della Democrazia Italiana.

Come riporta La Repubblica Il 10 luglio, è stato approvato dalla Camera un piano proposto dai Deputati dell’Unione Pietro Folena e Franco Grillini affinché vengano migrati tutti i computer del Parlamento da Windows a Linux.

La migrazione comprenderà obbligatoriamente circa 3500 macchine, sia desktops che servers, di uso “pubblico”, mentre ciascun Deputato e ciascuna segreteria di partito potranno anche migrare i propri computer (privati) a sistemi operativi Liberi.

Questa scelta è stata presa per varie ragioni… Innanzi tutto permetterà un bel risparmio economico, risparmando più di 3 millioni di Euro ciascun anno (le licenze di ciascuna macchina attualmente costano in media 900€ annui), ma si tratta anche di un bel passo avanti dal punto di vista della libertà ed indipendenza tecnologica, abbandonando sistemi proprietari che contrastano con il senso della Democracy stessa.
Tuttavia non vanno tralasciati i motivi tecnici che sono sostanzialmente legati alla sicurezza del Parlamento (e quindi a quella di tutti i cittadini).

Con questa decisione Folena spera che anche le amministrazioni locali inizino una migrazione verso sistemi liberi così come la provincia di Bolzano ha già fatto con il FUSS! project (di cui ne ha parlate anche Report).

Visto l’importanza della notizia (che finalmente pare rispettare il programma di Governo – dopo diversi erroracci), ho deciso di parlarne anche qui nonostante sia spesso restio a raccontare news di massa, ma anche di scrivere un articolo in inglese che spero possiate votare su digg (o diggare, se preferite) per dare una maggiore ampiezza a questa notizia anche a livello internazionale, dopo che è stata trattata quasi in sordina anche in Italia (quando ci si potrebbe vantare…).

EDIT [12-07-2007]: in base all’articolo del The Inquirer (che pare abbia intervistato Folena) oltre al fatto che si sottolinea che il passaggio sarà automatico per tutte le ~3500 postazioni pubbliche, mentre diventerà opzionale per 630 parlamentari (diventando così una delle migrazioni più imponenti in ambito amministrativo), si afferma che dal prossimo Settembre ed in circa 2 anni di switching, il Parlamento passerà a SuSE Linux e oggi [13-07-2007] Folena spiega brevemente che tale decisione è dovuta al fatto che la Camera aveva già un contratto con Novell e sfruttandolo anche per la migrazione si ridurrebbero anche i problemi ad essa collegati (mhmhm…).
Per un amante di Ubuntu come me non è esattamente la scelta migliore, ma anche se Novell ha fatto un patto con il Diavolo (leggasi Micro$oft) usa comunque il “nostro” kernel :P

Digg!
Grazie per aver votato questa notizia su Digg!

Compiz Fusion AMD-64 Ubuntu Repository

Compiz Fusion AMD 64 repositoryPrima della pubblicazione del MakeFusionDebs ho ricevuto davvero molte richieste dei pacchetti sorgenti per crearsi i pacchetti per la propria distribuzione ed architettura, successivamente mi ha fatto molto piacere vedere che in tantissimi si sono messi a creare pacchetti fatti in casa con il mio script ed ancora di più veder nascere repository per Debian Sid che lo sfruttano.

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.

Compiz Fusion inizia a parlare Italiano: Aiutiamolo!

Compiz Fusion Italian LogoCome avranno visto gli utilizzatori dei miei pacchetti o del mio script impacchettatore, da qualche giorno sia CompizConfig Settings Manager che i plugin di Fusion supportano l’internazionalizzazione (i18n).
Io, già da qualche giorno, ho ritirato fuori il mio vecchio mestiere da traduttore, e mi sono messo a tradurre CCSM (lavoro relativamente breve), ma quando è arrivato il momento dei Plugin di Compiz Fusion mi sono reso conto che non potevo fare da solo visto che ci troviamo davanti a quasi 500 stringhe (tra l’altro spesso molto tecniche), da rendere appetibili per gli utenti italiani…

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 informazionisezione 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 :P. 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) ^_^… 


EDIT [19-09-2007]: è tempo di fare un resoconto di quanto è stato fatto fino ad adesso.

Hanno contribuito (fin’ora):

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.

Impacchettare Compiz Fusion GIT con MakeFusionDebs

Make-Compiz-Fusion-ScriptCi siamo! Come avevo anticipato nel post precedente, mi sono messo di buzzo buono, ed ho terminato il lo script dinamico per impacchettare Compiz e Compiz Fusion direttamente da GIT.
Infatti, già quando iniziai ad impacchettare Beryl-SVN, come presupposto iniziale mi scrissi uno script che chiamavo rudimentalmentemakedebs‘ che mi permetteva di fare tutto il lavoro senza troppo sforzo e, sopratutto, senza necessità di una grossa manutenzione
Col breve passaggio di Beryl da SVN a GIT, aggiornai lo script per funzionare anche con il Software di Controllo delle Versioni Distribuito di Torvalds (= git) e con l’arrivo di CompComm (poi Compiz Fusion) l’ho aggiornato ulteriormente…

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:

git-clone git://anongit.opencompositing.org/users/3v1n0/compiz-fusion-debian-builder
cd compiz-fusion-debian-builder
./makefusiondebs

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:

./makefusiondebs                 # esegue tutti i passaggi (aggiorna ed impacchetta)
./makefusiondebs update          # esegue solo l’aggiornamento dei pacchetti
./makefusiondebs build           # impacchetta solo ciò che serve
./makefusiondebs <item>          # impacchetta solo <item> (se necessario)
./makefusiondebs rebuild <item>  # forza la ricompilazione di <item>
./makefusiondebs repack <item>   # forza il rimpacchettamento di <item>

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 ^_^ 

Bombardamento Mediatico da Compiz Fusion

Compiz-Fusion_test_logoA quasi una settimana dall’ufficializzazione del repository di Compiz Fusion, sembra proprio che il mondo se ne sia accorto… Infatti, a parte alcuni piccoli problemi riportati (e per lo più corretti) tra i commenti degli articoli di questo blog (dovuti soprattutto a dei bug di GNOME [nel caso dello splash eterno] od alla mancata rimozione di vecchi files [Segmentation fault o decorazioni mancanti]), pare che Fusion stia già conquistando il mondo Ubuntu e non solo…

Grazie a tutti quelli che mi seguono qui e nei forum internazionali, tutta questa foga si è riversata anche su di me e su quanto ho prodotto, venendo citato (ma non sempre linkato :() praticamente in ogni wiki, blog e forum in cui si parli di Ubuntu e Compiz Fusion facendo superare al repository, in poche ore, i 50’000 hit giornalieri (mentre il traffico è ancora lontano al record di 700Gb/mese di Febbraio rimanendo sotto i 400Gb/mese).
Come potete immaginare la cosa mi rende molto felice e non fa altro che stimolarmi a continuare e migliorare questa mia attività (se poi volete fare di più il pulsantino PayPal è tanto che se ne sta, tutto solo, nella sidebar di destra :P).

Tanto per farvi presente cosa intendo e per fissare nel DB dei risultati in un certo senso storici (ottenuti senza che mi impegnassi troppo direttamente nel segnalare la cosa e che hanno messo anche mezzo Tuxfamilyche ringrazio sempre – sotto sforzo), vi elenco i risultati che reputo più importanti:

Mi sembra di non aver dimenticato altro, ma già così mi pare un ottimo risultato… Mi scuso se non elenco tutti gli altri, ma capirete che non è possibile :)

Una richiesta che ricevo molto spesso in questi giorni, sono i sorgenti dei pacchetti deb, utili per gli utilizzatori di altre distribuzioni debian-based e/o altre architetture, bene… Nel tempo libero, tra una patch e l’altra, sto ultimando un sistema di impacchettamento dinamico (ossia che si auto-aggiorna da git) che renderà tutto molto semplice per tutti quelli che vogliono farsi dei pacchetti in casa. Ammetto di aver rallentato un po’ il suo sviluppo per dedicarmi ad altre cose, ma spero di terminare il tutto entro pochi giorni

Da CompComm a Compiz Fusion in formato .deb!

Compiz-Fusion-logo-testDopo il fallimentare sondaggio sul futuro nome di CompComm ed i flame che si erano scatenati in Mailing list per defnire quali nomi dovesero essere usati e chi li dovesse votare (e in che modo), immaginavo di dover continuare per (molte) altre settimane a dover buttare degli archivi .tar.gz nella cartella compiz-compcomm-name-in-progress della sezione xtra-debs del mio repository per tuti quegli impavidi che nei vari forum facevano di tutto per l’ultima versione del plugin firepaint :D e degli altri plugin rilasciati dai ragazzi di OpenCompositing, fin’ora innominabili.

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… :D

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 ;).

Configurare Compiz in scioltezza con CompizConfig!

CompizConfig LogoCome preannunciatovi nel post precedente, parliamo un po’ di nuovi sistemi di configurazione per Compiz sorti all’ombra di OpenCompositing.org… Come saprete compiz, fin dagli esordi, funzionava sfruttando il sistema di configurazione principe di GNOME: GConf, e questo elemento fu uno dei principali motivi di proteste da parte della comunità (spcialmente, quella non-gnome, ovviamente) e quindi della nascita di progetti paralleli (fork) quali compiz-quinn, prima e Beryl poi.

Con un certo ritardo (si sa, DavidR non è per i workaround… :P) 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
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! 

« Previous Entries