A fine 2009 era trapelata la notizia di una riscrittura in c++ del core di Compiz assieme ad una fusione con Nomad, una vera e propria rivoluzione che avrebbe portato ad un notevole miglioramento del famoso, sbarluccicoso, figoso, sbavoso window manager, il rilascio era previsto per dicembre ma poi non se ne seppe più niente, qualche ora fa Sam Spilsbury ha annunciato che il rilascio è vicino, si tratta solo di risolvere qualche bug, quindi probabilmente il mese prossimo potremo già provare il nuovo Compiz, tra le principali novità le API, framework e struttura rinnovati, una delle principali novità riguarderà i plugin: verranno divisi in ”Extension Plugins” e “Library Plugins“.
I primi sono stati creati per estendere la loro funzionalità ad altri plugin, interagendo con essi, tra questi troviamo per esempio “cubeaddon” e “animationaddon”.
I secondi, invece, vengono caricati in Compiz ma non svolgono nessuna funzione individualmente, forniscono funzionalità ad altri plugin, tra questi ci sono il “text plugin” o il “mousepoll plugin”. L’unico scopo dei “library plugins” è quello di fornire funzionalità ad altri plugin.
Grazie a questi cambiamenti il tutto verrà organizzato meglio e gli sviluppatori avranno minori difficoltà a scrivere estensioni aggiuntive e nuovi plugin. In poche parole, si tratterà di benefici utili sia per gli utenti che soprattutto per gli sviluppatori.
Usando Linux c’è da imbattersi in programmi scritti con librerie diverse da quelle usate dal DE (ovviamente parlo principalmente di gtk+ e Qt), e queste applicazioni sempre fanno esteticamente a pugni con l’ambiente circostante, nonostante si usino applicazioni esterne che permettono di arrangiarsi per quel che si può (uso qtcurve e gtk-kde4 per le applicazioni gtk) ma il risultato comunque salta all’occhio, e se su kde le cose vanno un pò meglio, su gnome un programma in qt è allucinante. Quale strada intraprendere quindi? Una soluzione, diciamo la più fattibile sarebbe quella di staccare il core dalla gui: prendiamo ad esempio Gimp, è scritto in C, e l’interfaccia in gtk+ (sempre C) perchè non continuare a scrivere il core in C e l’interfaccia in un linguaggio che si possa adattare a tutti desktop come il Python? Staccare questi due componenti non significa solo maggior pulizia del codice, ma vantaggi per entrambi gli sviluppi: una parte degli sviluppatori continua a sviluppare il core senza preoccuparsi della gui, quindi lo sviluppo può essere più veloce e può comprendere più features; una piccola parte di persone si occupa di fornire l’interfaccia al core, usando python che si integra perfettamente col c e la sua flessibilità permette di creare gui diverse utilizzando librerie diverse ma lo stesso linguaggio, e guardando oltre a gnome e kde si può fornire un’interfaccia anche a E17, a Windows e a Mac, usando la stessa base. Purtroppo serve una guida all’interno dei progetti che, più che saper programmare, deve saper gestire gli sviluppatori in base alle loro capacità e nel panorama Open difficilmente si sono viste persone capaci di ciò.
