Call for coders: I’m search few developers, check out the new post on this blog. I will release the new version when we’ll have a new murrine configurator (pygtk could be a simple solution)
Update 2: Complete alpha support, see GtkEntry for example and have fun Update 1: Screenshot showing quodlibet with alpha-capable window.
Since there’s a lot of confusion on the web, in the last week I’ve seen a lot of people claiming about “lacks” of Gtk+ capabilities.
Some of them still think that Gtk+ doesn’t have RGBA support. And if it has, it’s related to Cairo rendering just for special (custom) widgets. Or it will require nasty hacks.
This is absolutely false. And I will show you
Murrine with RGBA support
Yes, buttons have few problems with the contrast… but this is an alpha quality software!
Ehm… how we can get it?
First of all there’s the application support:
The application must set an rgba colormap (for example for the main window).
This will take 2 lines of code per widget (depending on the programming language).
Then you need the support of the Gtk+ engine:
The engine must be RGBA capable, like my development version of Murrine (not released and not available to the public, don’t ask for a release date now).
10 to 20 lines of code, and no hacks are required, just pure Gtk+ API!
And the good thing is that if you stop your composite window manager, the application will automatically looks like any other non-transparent app!
And of course a composite capable window-manager, like Compiz, future Metacity etc etc…
Conclusions
This could open a world of alpha-capable gtk+ applications with no-need of draw custom widgets, as the Gtk engine already draws them
Ho aggiunto il pacchetto metacity-compositor-svn, con cui potete provare il nuovo branch di metacity, con prestazioni 30% superiori su tutti i temi e supporto ad un compositor basato su Xrender!!! Ora la velocità, grazie al boost del 30%, è paragonabile se non maggiore a quella di Kwin, con l’incredibile vantaggio dell’imbarazzante maggior numero di temi a disposizione e la facilità nel creali!
Per attivare le ombre basta abilitare l’estensione Composite in xorg.conf, lanciare gnome, e dare il seguente comando da terminale (oppure usare gconf-editor):
Con questa versione (in sviluppo, ricordo) non funziona più il gestore dei temi, quindi questi vanno specificati a mano con l’editor di configurazione.
Pertanto potete scegliere fra:
Non aggiornare finchè questo problema non viene risolto (vi avviserò qui nel blog quando tutto sarà ok).
Aggiornare e modificare le impostazioni dell’interfaccia tramite gconf-editor
Se dovete cambiar tema e non volete rinunciare all’interfaccia grafica date un “pacman -S metacity”, lanciate la gui, poi un “pacman -S metacity-compositor-svn”
Piccole Considerazione
Questo branch di metacity non si pone come alternativa a Compiz (come invece fa il compositor di Kde4), bensì come un supporto stabile e funzionante su praticamente tutti i computer all’estensione composite (che permetti di usare le trasparenze come avant-window-navigator, screenlets, etc etc).
Usa Xrender e non OpenGL, quindi le prestazioni talvolta possono essere peggiori (nel caso abbiate una scheda video con un rendering OpenGL abbastanza veloce).
Insomma usate Compiz se avete un pc che ve lo supporta, se vi piace dannarvi l’animo con mille configurazioni e se non vi sembra troppo giocattoloso
“Se quello che abbiamo adesso si fosse chiamato 1.0, allora adesso saremo di fronte a qualcosa classificabile come 2.0″
Il signor DavidR (David Reveman) parla (scrive eheheh) in mailing list sullo stato attuale di compiz e gli sviluppi futuri.
Non contento infatti della architettura attuale e della difficoltà nell’apportarne miglioramenti, sembra che abbia pronto in cantiere una completa riscrittura che proprio per i miglioramenti potrebbe benissimo essere chiamata 2.0. Dico “potrebbe” perchè è più probabile che il nome sarà in realtà 1.0 per seguire la solita logica del versioning in linux, ciò nonostante questa nuova versione costituirà una base eccezionale per gli sviluppi futuri.
Proprio ieri dicevo ad un mio amico che lo sviluppo di compiz sembrava rallentare in modo preoccupante, che DavidR fosse sparito, eccetera eccetera… Ebbene a distanza di poche ore è lui stesso a smentirmi…
…e sono contento che l’abbia fatto
Vi riporto il testo della mail originale, che è meglio di averne una mia traduzione. Se non capite posso tradurne dei pezzi.
I’d like to start with apologizing for my lack of response to the
mailing list for the last couple of months. I’m working my way through
all posts right now…
Here’s what I’ve been up to lately..
I did a critical review of the state of compiz about 6 months ago. I
realized it was pretty bad (not that there’s actually anything better
out there but still), it’s hard to maintain, hard to write proper code
for and in some ways not dynamic enough for people to do what they want.
None of the features I need to implement can be done properly in the
current architecture.
I spent a lot of time trying to come up with a way for us to re-engineer
the core of compiz and fix all the issues that exist in the current
architecture. I did a fair amount of research and experimenting before I
got an idea of what would be a good future architecture. What’s emerging
in the object-framework branch is the result of this work and what I
believe to be the best way forward. There’s still some important pieces
missing before I consider merging it to master a good idea but it’s now
at least at a stage where I’m comfortable with people starting to look
at it and start discussing merging it to master.
Even though I’ve made sure that the rewrite allows existing plugins to
be fairly easily ported, it’s still going to be the most significant
change to compiz since the initial version was realized. If we ever had
released a 1.0, this would definitely qualify for a 2.0.
Most of the ground work for this new architecture has already been done
in the object-framework branch but even when we’ve gotten it to a state
where it can be merged, there’s still a lot of work left to make the
existing core functionality and plugins take advantage of it. However,
the considerably more modularized nature of this new architecture would
allow us to move to a much smaller core and get it ready for a 1.0
release in a short amount of time.
I’m going to send a series of posts to the list that explains the
different parts of the new architecture in more detail (hopefully the
first one during the weekend) but here’s a few key features of the new
architecture:
A strict hierarchical structure. A very well-defined way for how the
different parts of the system communicate with each other (it’s obvious
when some code is doing something inappropriate and it’s also hard to
write code that is doing something inappropriate). Whether the code is
in the core or in a plugin is of no significant importance, which means
that pretty much anything can be modularized. Plugins can be inserted
into different parts of the object tree and only affect a sub-tree of
objects. An internal communication system that maps efficiently and
conveniently to various IPC systems.
Vista la bontà del repository di nesl247, ho deciso di non disperdere troppo le mie risorse, fermando gli aggiornamenti del mio repository e suggerendo quello di nesl247 (da usare con il repository testing abilitato):
[compiz-fusion]
Server = http://arch.nesl247.org/compiz-fusion/i686
[compiz-fusion]
Server = http://arch.nesl247.org/compiz-fusion/x86_64
La qualità è ottima (anche se viene aggiornato un pelino di meno), quindi d’ora in avanti usate pure questo.
gnome-svn
gnome-svn continuerà invece ad essere aggiornato. Ricordo il link:
[gnome-svn]
Server = http://cimi.netsons.org/arch/i686
Il repository per gnome 2.19 per arch è stata una delle sorprese più gradite ed inaspettate che mi potessi aspettare, e così vi annuncio che i miei repository si allineeranno con quest’ultimo.
il repository per gnome diverrà gnome-svn (per non far casino di nomi), mentre quello di compiz, rinominato compiz-fusion risulterà compatibile soltanto con l’ultima versione di gnome: 2.19/2.20, quindi:
NON FATE L’UPGRADE SE NON STATE UTILIZZANDO GNOME 2.19/2.20
Ho aggiornato la repository di compiz, utilizzando i pkgbuild di nesl247, che ringrazio (thanks!)
Avvertenza
Ho scelto di usare i pkgbuild di nesl247, quindi a questo punto il mio repo diventa quasi un mirror del suo, solo aggiornato in giorni differenti e con un supporto italiano (io) nel caso qualcuno abbia bisogno
Se volete potete usare il suo, se volete il supporto italiano fate qui
Qualche giorno fa è uscita una nuova versione delle screenlets, la dashboard per il nostro pinguino, utilizzante cairo e le immagini vettoriali (cosa che noi gnommari facciamo già non abbiamo bisogno di plasma LOL). Link al thread sul forum di Compiz
ChangeLog
0.0.9:
new tabbed layout in Properties-dialog (e.g. new Themes-tab)
improved MailCheck (now uses keyring to store passwords, NOTE: passwords are only stored for the current session yet)
improved Launcher (now supports drag&drop of menu-entries from Applications-menu)
improved CPUMeter (including new theme)
improved Notes (far better, yet still buggy, keyhandling)
new “protected”-options (not accessible through dbus)
faster startup and resizing (hopefully)
improved theme-system, most themes can now be created from _either_ PNG _or_ SVG images (except the Clock), I hope to see some more themes now Wink
many more details in changelog …
0.0.8:
new session-system: screenlets are now intended to be launched separately and support multiple sessions (the screenlets-daemmon is still supported to ensure backwards compatibility with third-party screenlets, but shouldn’t be used anymore and will get removed sooner or later)
screenlets not run within one process anymore, each screenlet-type has its own process and automatically handles multiple instances within that process
all screenlets now have own dbus-services and can easily interact with other applications and/or offer custom services (like org.screenlets.Clock or org.screenlets.Notes), this offers very amazing possibilites for the developer
new PicframeScreenlet, FlowerScreenlet and StorageScreenlet (some of them still quite unfinished)
added drag&drop support to baseclass and some of the screenlets (Picframe can receive images through drag&drop, Notes can receive text, …)
separated code into several modules
various bugfixes and optimizations
… see changelog in package for a full list of changes (there are quite a few …)
Alcune delle parti più importanti di quando si sviluppa un software sono le API e la modularità. Le API in questo caso non ci interessano (purtroppo sono invece una gravissima mancanza di Tracker)… mentre la modularità eccome!
Avrete già notato infatti che negli ultimi mesi (se escludiamo la patch per il look alla looking glass) awn ha avuto un sacco di aggiornamenti ma nulla di nuovo “visivamente”. In realtà Neil non se ne è stato con le mani in mano ed ha lavorato moltissimo sulla modularità.
La modularità è quel qualcosa che rende un software potente, che gli da la possibilità di migliorarsi ed espandersi a velocità incredibili
Ed è proprio quello che vi dimostrerò con questo post
Preparatevi perchè ne vedrete davvero delle belle.
Usa la forza Luke!
…Ovvero che c’è di nuovo che bolle in pentola.
Stack:
Cominciamo da questa applet in sviluppo, che si è ispirata a stack ma che risulta più usabile, con un menù a tendina più organizzato e comodo.
Temi:
Continuiamo giochicchiando con un gestore di temi in pygtk:
Gnome Menu:
Eh sì… perchè non aggiungere il menu?
Applet Dialog:
Ci avete pensato anche voi vero? Ma non è affatto difficile realizzarle: Screenshot.
Hover Effects:
Questa non è una Applet ma una patch per aggiungere altri effetti: Link al video
Il Futuro?
Se ciò che avete visto non non vi è bastato ecco un’idea, molto plasmoide, sull’utilizzo di applet vettoriali. Neil dice “eh si alla versione 0.3 però!”, ma in fondo noi siamo qua ed aspettiamo, sapendo che prima o poi qualcuno scriverà qualcosa di simile:
Dopo la fusione bisognava chiarire un po’ le idee… Armatevi di pazienza e leggetevi con calma ed attentamente ciò che segue… Alla fine vi sembrerà tutto più chiaro
Cercherò di essere il più possibile schematico così da rendere più semplice la comprensione…
Come è strutturato “Compiz”
La struttura è la seguente:
Core, il programma “compiz” che viene lanciato
Plugins Ufficiali, senza plugins “compiz” non è praticamente niente, come un kernel senza programmi, una shell senza binari installati… Questi sono quelli di base, con pochi effetti, ma sviluppati con maggior attenzione all’usabilità
Plugins della Community, sono i plugins sviluppati dalla community, rappresentano gran parte del progetto “Compiz Fusion” e comprendono tutti quei plugin più “esotici”, come il cubo riflettente, expo dei desktop, ring switcher, animazioni…
Decoratori di finestre, come Emerald, Gtk-window-decorator, Kde-window-decorator…
Utilità di configurazione, come CCSM, aka CompizConfig…
Programmi esterni, come le trayicons…
Cos’è il Core e cosa sono i Plugins
Come precedentemente detto, compiz senza plugins non è niente.
E’ necessario quindi lanciare questi plugins, che svolgono funzioni di ogni tipo: c’è un plugin per il ridimensionameno (resize), uno per lo spostamento delle finestre (move), uno per le decorazioni (decoratation), uno per il cubo (cube), uno per le “finestre tremolanti” (wobbly) etc etc…
Ce ne sono quindi di tutti i gusti, e costituiscono le “funzionalità” di Compiz. Immaginatevi quindi “compiz” (il programma che lanciate da terminale o da dove volete) come il “kernel” che gestisce l’accesso alla scheda video. I plugins a loro volta si interfacciano ad esso e producono gli effetti e le funzionalità che poi vediamo.
E’ indispensabile quindi che il Core sia stabile ed il più possibile “centralizzato” (da questo si capisce l’importanza della fusione in seguito ad un dispersivo fork come è stato per Beryl)
L’avvio dei Plugins
Come saprete compiz viene lanciato generalmente con:
compiz --replace gconf
Ma una volta le cose non stavano così, ai tempi di XGL, un annetto fa per chi c’era… Ma cosa significa???
Al di là di quel “--replace” (che sarebbe essenzialmente la flag per dirgli di sostituire qualsiasi gestore di finestre attivo, metacity, kwin, xfwm etc etc…) la sintassi utilizzata è la seguente:
compiz --replace PLUGIN1 PLUGIN2 PLUGIN3…
Ad esempio per lanciare compiz con la possibilità di muoverlo, il ridimensionamento e le decorazioni basta lanciare:
compiz --replace move resize decoration
Se c’è qualcuno che si ricorda, infatti, agli inizi si lanciava compiz con lunghissime stringhe di plugin da lanciare, il che ovviamente era scomodo, perchè obbligava al riavvio di compiz tutte le volte che si voleva lanciare un plugin nuovo (oltre ad essere scomodo…)
Ma per ovviare a questo problema era nato il plugin gconf.
Il Plugin Gconf
Il plugin gconf fu il primo tentativo di subordinare l’avvio dei plugins ad un plugin stesso!!!
Gconf infatti è un semplice plugin che gestisce le impostazioni e l’avvio selettivo ed in tempo reale di altri plugins.
Sotto la voce “active_plugins”, utilizzando gconf-editor, è possibile aggiungere e rimuovere i plugins attivi, guadagnando in ordine ed in velocità.
Così quando lanciate compiz --replace gconf accade che compiz lancia subito il plugins gconf, il quale a sua volta (è la funzionalità del plugin) lancia tutti i plugins richiesti… (ad esempio basta aggiungere move, resize, decoration dentro la voce active_plugins per lanciarli).
Allo stesso tempo controlla se vengono fatte modifiche alle impostazioni dei plugins… che vengono salvate/caricate sempre dal demone gconf (il plugin gconf scrive le sue modifiche sul demone omonimo di gnome).
Beryl ed il suo Plugin per le opzioni
Beryl non salvava su gconf… utilizzava file di testo che poteva essere editato mediante il “Beryl Settings Manager”. Ma come faceva???
Evidentemente non lanciava beryl --replace gconf ma qualcos’altro, tipo beryl --replace BerylSettings (scusatemi ma non so come si chiamava). BerylSettings era pertanto un plugin che aveva funzionalità simili al plugin gconf, ma che scriveva su semplici file di testo.
Il Plugin Ini
Il plugin ini è stato aggiunto recentemente a Compiz e permette di fare esattamente quello che il plugin gconf fa attraverso gconf, ma scrivendo su file di testo.
Si tratta quindi di un porting migliorato dell’efficiente plugin di salvataggio di Beryl, utilizzato di default da Beryl stesso. (ricordate che beryl non usava gconf?)
Il Plugin Ccp
Il plugin ccp è un nuovissimo plugin frutto della fusione, e permette di lanciare tutti i plugin settati dal configuratore.
In pratica, un avvio del tipo:
compiz --replace ccp
lancerà a sua volta tutti i plugin abilitati nel configuratore, risolvendo dipendenze e svolgendo il lavoro completamente in automatico.
Che figata, ed il bello è che sembra funzionare veramente bene
La Configurazione tramite CompizConfig
Il plugin ccp “legge” i settaggi che avete impostato in CompizConfig e lancia tutti i plugin richiesti. Se abilitate un nuovo plugin tramite il configuratore lui provvederà a lanciarlo, senza alcuna modifica manuale a gconf (che non è nemmeno più richiesto).
Il configuratore può poi utilizzare diversi backend (dove salvare i files):
Flat file configuration
Gconf backend
Di base viene fornito con la configurazione testuale (i settings si trovano nella home nella directory ~/.compizconfig), ma volendo si possono riutilizzare i settings di gconf e salvarli direttamente lì: basta installare il pacchetto con pacman (compizconfig-backend-gconf) e selezionare il backend voluto (premete il pulsante in basso a sinistra per accedere alla schermata per la selezione del backend).
CompizConfig è il corrispettivo (svolge una funzione analoga) di Beryl Settings Manager del vecchio Beryl. In più però, questo CompizConfig è indipendente dai plugin installati, ovvero installando nuovi plugins lui aggiungerà automaticamente le nuove voci, senza dover installare una versione aggiornata di CompizConfig!
Decoratori
Potete installare 3 configuratori diversi:
Gtk-window-decorator, conosciuto brevemente come gwd, può utilizzare i temi di metacity
Kde-window-decorator, conosciuto brevemente come kwd, può utilizzare i temi di kwin
Emerald, il vecchio decoratore di beryl, con i suoi orrendi temi che possono essere scaricati da gnomelook
I primi due sono sviluppati in compiz-core e vengono forniti praticamente di default, il terzo è installabile a parte (pacchetto emerald-git).
Per funzionare, richiedono che il plugin decoration sia abilitato.
Programmi Esterni
Giusto per ricordare… è in sviluppo una trayicon (compiz-icon), che funziona e non funziona (io ho trovato già 3 grossi bug nonostante non capisca niente di python). Va fatta funzionare con dei workaround finchè non fixeranno i bug
Ricordo pure uno stralcio di manager per l’avvio di compiz, chiamato compiz-manager.
Conclusioni
Spero di aggiornare questo articolo perchè l’ho scritto molto di fretta, essendo veramente impegnato ultimamente… però mi sembrava giusto scriverlo per fare un sunto della situazione…
Spero abbiate gradito lo sforzo
Se volete potete installare anche compiz-fusion-plugins-extra-git, che sarebbero i plugins ancora più tamarri/truzzi, comunque vi spiegherò meglio un altro giorno.
Ho anche provato a compilare il backend di gconf al configuratore di compiz ma è altamente scassato :D, meglio non usare gconf al momento… (infatti non l’ho nemmeno aggiunto alla repository)
(pygtk could be a simple solution)
non abbiamo bisogno di plasma LOL). 
…) 
