The news spread out quite quickly, once last Friday Jonas pressed the button and that triggered the last-second merge for the relevant proposals we prepared for Mutter and GNOME Shell in order to get this available for GNOME 3.32.

As someone might recall, we started this work some years ago (ouch!) and lead to an Hackfest in Taipei, but in between other work to do and priorities which caused this to be delayed a bit. While the first iteration was ready for some time now. But at every review we improved things fixing bugs (like missing scaled widgets) and optimizing some code paths, so hopefully this time helped in serving better quality :).

We’ve still quite a lot of work to do (see these issues for mutter and shell) and some fixes that we have in queue already, but the main task is there. So starting from now the shell will paint all its elements properly and in good visual quality at any fractional scaled value, and independently for every monitor.

Monitors with different scaling values, and a window drawn in between the two

As you might have noticed in the screenshot above, the X11 apps are still not really scaled in quality, while it’s not possible for them all (like xterm there), we need to work for a solution that will cover the legacy applications which does support scaling, and at the same time those which doesn’t want to be scaled at all (games!).

As per what said above, this feature is still considered experimental and then you need to enable it via:

gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"

Doing this will allow you to set more a wider set of scaling values under Control Center, display panel.

For what concerns Extensions, most of them should work with no change, but not those using directly the St.TextureCache, as we changed the methods signature by adding a resource_scale parameter.
We discussed weather adding another method instead (as gir doesn’t support default values), but since 3.32 will need anyway a rewrite of most extensions anyways, and since it’s better to have them to behave properly with resource scale since the beginning (instead of blurred contents), we decided not to do it.
So, please sync with this change (and sorry :)).

Putting my Ubuntu hat now, this won’t change much things for default ubuntu experience, since it’s still using X11 (although I’ve something in the works for this too), but people who want to take advantage of this can easily just login using the Ubuntu on Wayland session, enable the experimental setting and profit.

As final world, thanks to people who helped having this in by reviewing and testing the code.

I’m writing these lines while I’m in the flight to Almeria where this year’s GNOME Users And Developers European Conference will take place, typing with my Thinkpad Bluetooth keyboard on my mobile phone (I’ve to admit that the Android physical keyboard usage is getting awesome, allowing proper WM actions) :), as the battery of my T460p was already over after the flight from Florence to Madrid during which I fixed some more shell JS errors.

This will be my first GUADEC ever, and as a fresh Foundation member, I’m quite excited to finally join it.

I’m not coming alone, of course, as this year the ubuntu-desktop team will be quite crowded, as me, Ken VanDine, Sébastien Bacher, Didier Roche, Iain Lane, James Henstridge and Robert Ancell will be part of the conference, to give input and help to get GNOME even better.

Soo, looking forward to meet you all very soon (almost landed – or better – trying to, in the mean time)!

As always, I’ve to thank Canonical for allowing me and the desktop crew to be part of this great community reunion. But also for being one of the silver sponsors of the event.

These are the events that really matter in order to get things done.

Since people asked, as I’ve set in the /whois, I’m the man behind it, and it’s actually running for some time from a snap inside a cloud instance I manage and hosted by Canonical.

This was just a quick-hack (so take it as it is) I did as I was annoyed by  not to getting the bug infos when linking the the always increasing references to GNOME or Debian projects. The source-code is here, while configuration files (can provide samples if curious) are just enabling the minimum necessary for having this joining the channels and disabling all the other plugins.

However, it currently supports parsing issues and merge proposals for Github and various Gitlab instances (gitlab itself, Freedesktop, GNOME, and Debian Salsa)

Yeah, I know:

• There are other bot options, but I just wanted to hack something quickly
• It should be moved to git, cleaned up removing the unused bugzilla stuff
• Supybot should be replaced with its new fork Limnoria
• I should host the code in a GNOME gitlab project together with the configuration (without the API tokens, of course)
• Jonas asked for colors

I’ll probably do this once I’ve some free time (hard to find, in between my travels), but in the mean time, in case this bothers you, let me know, if instead want it to join other channels, tell me too

EDIT 31/05: added Freedesktop gitlab too
EDIT 22/08: project code added to gitlab, bot is now named gitbot in freenode

So, thanks again, and sorry for my late “hello”

As this being said I’ve to thank my employer, for allowing me to do this and for sponsoring the event in order to help making GNOME a better desktop for Ubuntu (and not only).

Going deeper into the event (for which we tracked the various more technical items in a WIP journal), it has been a very though week, hard working till late while trying to look for the various edge cases and discovering bugs that the new “logically sized” framebuffer and actors were causing.

In fact, as I’ve already quickly explained, the whole idea is to paint all the screen actors at the maximum scale value across the displays they intersect and then using scaled framebuffers when painting, so that we can redefine the screen coordinates in logical pixels, more than using pixel units. However, since we want to be able to use any sized element scaled at (potentially any) fractional value, we might incur in problems when eventually we go back to the pixel level, where everything is integer-indexed.

We started by defining the work items for the week and setting up some other HiDPI laptops (Dell XPS 15 and XPS 13 mostly) we got from the office with jhbuild, then as you can see we defined some list of things to care about:

• Supporting multiple scaling values: allowing to scale up and down (< 1.0) the interface, not only to well-known value, but providing a wider range of floats we support
• Non-perfect-scaling: covering the cases in which the actor (or the whole monitor) when scaled up/down to a fractional level has not anymore a pixel-friendly size, and thus there are input and outputs issues to handle due to rounding.
• GNOME Shell UI: the shell StWidget‘s need to be drawn at proper resource scaling value, so that when they’re painted they won’t look blurred.
• Toolkit supports: there are some Gtk issues when scaling more than 2x, while Qt has support for Fractional scaling.
• Wayland protocol improvements: related to the point above we might define a way to tell toolkits the actual fractional scaling value, so that they could be scaled at the real value, instead of asking them to scale up to the upper integer scaling level. Also when it comes to games and video players, they should not be scaled up/down at all.
• X11 clients: supporting XWayland clients

What we did

As you see the list of things we meant to work or plan was quite juicy, so more than enough for one week, but even if we didn’t finish all the tasks (despite the Super-Joans powers :-)), we have been able to start or address the work for most of them so that we’ll know what to work on for the next weeks.

Scaling at 1.25x

As a start, we had to ensure mutter was supporting various scaling values (including the ones < 1.0), we decided (this might change, but given the Unity experience, it proved to work well) to support 8 intermediate values per integer, from 0.5 to 4.0. This, as said, would lead to troubles when it comes to many resolutions (as you see in the board picture, 1280×720 is an example of a case that doesn’t work well when scaled at 1.5 for instance). So we decided to make mutter to expose a list of supported scaling values per each mode, while we defined an algorithm to compute the closest “good” scaling level to get a properly integer sized logical screen.
This caused a configuration API change, and we updated accordingly gnome-settings-daemon and gnome-control-center adding also some UI changes to reflect and control this new feature.
Not only, the ability of having such fractional values, caused various glitches in mutter, mostly related to the damage algorithm, which Jonas refactored. Other issues in screenshots or gnome-shell fullscreen animations have also been found and fixed.

Speaking of Gnome Shell toolkit, we started some work to fix the drawing of cairo-based areas, while I had already something done for labels, that needs to be tuned. Shih-Yuan fixed a scaling problem of the workspace thumbnails.

On toolkits support, we didn’t do much (a part Gnome Shell) as Gtk problem is not something that affects us much in normal scenarios yet, but still we debugged the issue, while it’s probably a future optimization to support fractional-friendly toolkits using an improved wayland protocol. Instead it’s quite important to define a such protocol for apps that don’t need to be scaled, such as games, but in order to do it we need feedback from games developers too, so that we can define it in the best way.

Not much has been also done in XWayland world (right now everything is scaled to the required value by mutter, but the toolkit  will also use scale 1, which would lead to some blurred result), but we agreed that we’d probably need to define an X11 protocol for this.

We finally spent some time for defining an algorithm for picking the preferred scaling per mode. This is a quite controversial aspect, and anyone might have their ideas on this (especially OEMs), so far we defined some DPI limits that we’ll use to evaluate weather a fractional scaling level has to be done or not: outside these limits (which change depending we’re handling a laptop panel or an external monitor [potentially in a docked setup]) we use integer scaling, in between them we use instead proportional (fractional) values.
One idea I had was to see the problem the other way around and define instead the physical size (in tenth of mm) we want for a pixel at least to be, and then scale to ensure we reach those thresholds instead of defining DPIs (again, that physical size should be weighted for external monitors differently, though). Also, hardware vendors might want to be able to tune these defaults, so one idea was also to provide a way for them to define defaults by panel serial.
In any case, the final and most important goal, to me, is to provide defaults that guarantee usable and readable HiDPI environments, so that people would be able to use gnome-control-center and adjust these values if needed.
And I think could be quite also quite useful to add to the gnome-shell intro-wizard an option to chose the scaling level if an high DPI monitor is detected.
For this reason, we also filled this wiki page, with display technical infos for all the hardware we had around, and we encourage you to do add your infos (if you don’t have write access to the Wiki, just send it to us).

What to do

As you can see in our technical journal TODO, we’ve plenty of things to do but the main thing is currently fixing the Shell toolkit widgets, while going through various bugs and improving the XWayland clients situation. Then there multiple optimizations to do at mutter level too.

When we ship

Our target is to get this landed by GNOME 3.26, even if this might be under an experimentalgsettings key, as right now the main blocker is the X11 clients support.

How to help

The easiest thing you can do is help testing the code (using jhbuild build gnome-shell with a config based on this) should be enough), also filling the scale factor tests wiki page might help. If you want to get involved with code, these are the git branches to look at.

Read More

You can read a more schematic report that Jonas wrote for this event on the gnome-shell mailing list.

Conclusions

It has been a great event, we did and discussed about many things but first of all I’ve been able to get more closely familiar in the GNOME code with who has wrote most of it, which indeed helped.
We’ve still lots of things to do, but we’re approaching to a state that would allow everyone to get differently scaled monitors at various fractional values, with no issues.

Our final board

Check some other pictures in my flickr gallery

Finally, I’ve to say thanks a lot to Jonas who initially proposed the event and, a part being a terrific engineer, has been a great mate to work and hang out with, making me discover (and survive in) Taipei and its food!

Although I see the technical reason for that (pixels can’t be divided!), I think that our approach still worked quite well by using proper round functions, as it’s really hard to notice the visual flaws that this introduced at such high resolutions.

At the same time, to get proper scaling for GTK apps, we used the stratagem of mixing the UI scaling with the text scaling factor, so that the multiplication between the two values will match the user-requested scaling level.
This worked pretty well in single-monitor instances, while in multi-monitor environments the idea was to use xrandr scaling to get matching results, but this has not been done, mostly due to an X11 bug which didn’t allow to go further…

Anyway, this is the past and present, but let’s talk about the future… Ubuntu will use GNOME Shell (in Wayland, when possible), and so far there’s no support for multi-monitor scaling or fractional scaling, but things are changing!

Jonas Ådahl is leading this efforts and he started with supporting a new configuration API for monitors, that is a prerequisite for pursuing the GNOME Fractional Scaling initiative.
Basically, the main implementation idea is to make GTK and various toolkits to scale at an higher value, and then using mutter to scale actors down at composition level.
While it might be a little more resource intense, it’s also true that this will work nicely (especially in multi-monitor environments with different scaling values) and that there’s no other option, given that GTK scaling system can’t be changed at this point (too many things now assume it’s an integer).

Ubuntu cares about having a proper HiDPI support in next releases, so the Desktop Team decided to join the upstream initiative, and since I’m currently around asia, we’ve organized a GNOME Hackfest, that will be hosted by Canonical in its Taipei office in Taipei 101 in order to continue the work Jonas is doing and plan how to proceed with future work items.

As you surely know, in the past weeks Ubuntu took the hard decision of stopping the development of Unity desktop environment, focusing again in shipping GNOME as default DE, and joining the upstream efforts.

While, in a personal note, after more than 6 years of involvement in the Unity development, this is a little heartbreaking, I also think that given the situation this is the right decision, and I’m quite excited to be able to work even closer to the whole opensource community!

Most of the aspects of the future Ubuntu desktop have to be defined yet, and I guess you know that there’s a survey going on I encourage you to participate in order to make your voice count…

One important aspect of this, is the visual appearance, and the Ubuntu Desktop team has decided that the default themes for Ubuntu 17.10 will continue to be the ones you always loved! Right now some work is being done to make sure Ambiance and Radiance look and work good in GNOME Shell.

In the past days I’ve released a  new version of ‘light-themes‘ to fix several theming problems in GNOME Shell.

This is already quite an improvement, but we can’t fix bugs we don’t know about… So this is where you can help make Ubuntu better!

Get Started

If you haven’t already, here’s how I recommend you get started.
Install the latest Ubuntu 17.10 daily image (if not going wild and trying this in 17.04).
After installing it, install gnome-shell.
Install gnome-tweak-tool if you want an easy way to change themes.
On the login screen, switch your session to GNOME and log in.

Report Bugs

Run this command to report bugs with Ambiance or Radiance:

ubuntu-bug light-themes

Attach a screenshot to the Launchpad issue.

Other info

Ubuntu’s default icon theme is ubuntu-mono-dark (or -light if you switch to Radiance) but most of Ubuntu’s customized icons are provided by humanity-icon-theme.

Helping with Themes development

If you want to help with the theming itself, you’re very welcome. Gtk themes are nowadays using CSS, so I’m pretty sure that any Web designer out there can help with them (these are the supported properties).

All you have to do, is simply use the Gtk Inspector that can be launched from any Gtk3 app, and write some CSS rules and see how they get applied on the fly. Once you’re happy with your solution, you can just create a MP for the Ubuntu Themes.

Let’s keep ubuntu, look ubuntu!

PS: thanks to Jeremy Bicha for the help in this post.

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

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?

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:

Visita TuxFeed.it

Bye  

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

Grazie per aver votato questa notizia su Digg!

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

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

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 Tuxfamily – che ringrazio sempre – sotto sforzo), vi elenco i risultati che reputo più importanti:

• Digg – Fantastic Ubuntu Feisty Eye Candy Repository (con oltre 1000 diggate, finito anche in homepage; è già la terza volta per il mio sito – la seconda in home – ma mai un impatto del genere)
• Vorian – How To: Compiz Fusion (postato in Planet Ubuntu da Stephen Stalcup)
• SkyIsGrey – Compiz Fusion In Feisty! (postato in Planet Ubuntu da Andy Apdhani!)
• UbuntuForums – How To: Compiz Fusion on Ubuntu 7.04 (thread in rilievo nella sezione Desktop Effects)
• Softpedia – How to Install Compiz Fusion on Ubuntu (news anche da Softpedia!)
• Pollycoke – Ubuntu Feisty + Compiz Fusion (beh, Felipe è Felipe…)

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…

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… :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 – 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 :P).

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

Infatti, dopo la lettera della Telcom Italia ricevuta dal mio comune nel Febbraio di quest’anno in cui si rendeva nota la pianificazione del servizio ADSL per il I semestre del 2007, e l’ufficializzazione nel sito wholesale di Telecom Italia avvenuta i primi di Maggio (che io ho scoperto e di cui ha riportato la notizia mio cugino AleXit) in cui – cripticamente – si parlava del 31 Giugno, e ancora, dopo che la centrale principale di Prato di Strada – situata accanto a casa mia (anzi, in un certo modo è casa mia visto che lo stabile è di proprietà di mia nonna) – è stata “assalita” senza interruzione da Omini Telecom per tutto il mese: quest’oggi, dopo che un primo controllo di routine fatto nel primo pomeriggio aveva avuto esito negativo, AleXit mi ha avvertito che qualcosa era cambiato, ed ecco cosa:

Come potete vedere, dopo anni di niet, adesso il semaforo di toscanini è finalmente verde!

Potrete sicuramente (o forse no?!) immaginare la gioia che una notizia del genere possa suscitare in uno smanettone informatico che ha fatto della Rete la sua seconda casa, vissuto fino a 21 anni senza banda larga (ormai dovrebbe essere un diritto costituzionale :D)…
Magari avrei sentito la necessità di una connessione broadband più qualche anno fa (ai tempi del Liceo…) visto che ora sto poco in casa e non abuso troppo della banda, ma vi assicuro che fin’ora la mia vita informatica non è stata sempre in discesa…

Nel mio caso, è apparso anche il messaggio «Servizio disponibile con intervento tecnico preventivo» visto che attualmente ho in casa una linea ISDN che dovrà essere rimossa, ma su questo e sui miei trascorsi telematici vi farò sapere in futuro…

Attualmente il servizio è disponibile per le numerazioni 570xxx, 572xxx e 550xxx (già disponibile da tempo essendo gestiti dalla centrale di Borgo alla Collina), mentre non è ancora disponibile per le numerazioni 555xxx (della centrale di Cetica, la cui attivazione è prevista sempre per fine giugno).

Ora, non mi resta che decidere quale servizio acquistare, siccome ho un vecchio contratto flat (dialup) con Tiscali di cui non avevo potuto ancora chiedere la disdetta, per evitare di pagare altri mesi inutilmente pensavo di usare quello, però posso avere al massimo una 4Mb. Altrimenti, c’è sempre la cara Mamma Telecom con cui, vista la distanza dalla centrale, non dovrei avere problemi ad avere una bella 20Mb, ma non so bene come funzioni… Quindi fatemi sapere!

PS: Ovviamente, io e alex abbiamo messo l’annuncio su www.comune.castel-san-niccolo.ar.it

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à :D), 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 :P, 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à

Ve l’avevo promesso un paio di giorni fa e sono stato di parola… Dopo avervi “ufficializzato” il repository 3v1n0, adesso è la volta di un altro progetto che ormai si sussegue di versione in versione ad ogni rilascio di Ubuntu: la lista(ona) dei repository di terze parti.

L’indirizzo non è ancora cambiato, per tanto potrete trovare la sources.list aggiornata per Feisty Fawn sempre in questa pagina: Lista Repository (sources.list) per Ubuntu / Kubuntu Feisty Fawn.

Anche in questa versione, per tenervi aggiornati in modo più efficace ho creato un pacchetto (3v1n0-sources-list) che si trova nel mio repository e che aggiornerò ad ogni modifica sostanziale della lista…
Come già detto questo piccolo .deb non fa altro che sostituire la vostra sources.list con la "mia", ovviamente dopo aver fatto i backup del caso (sempre in /etc/apt/), potete quindi installarlo da qui:

• 3v1n0-sources-list_0.4-3v1ubuntu0feisty1_i386.deb

Dopo l’installazione non dimenticare di lanciare un sudo apt-get update per avere tutti i nuovi software e gli aggiornamenti!

In questa versione ho deciso anche di facilitare una delle operazioni più noiose connesse all’aggiornamento della lista, ossia l’approvazione della chiave GPG dei repository di terze parti. Nella Pagina della lista (non nel pacchetto), infatti ho inserito uno script che potrete incollare nel vostro terminale per fare un riconoscimento rapido. Ci tengo a sottolineare comunque che non mi assumo le responsabilità dell’approvazione di tutti i repository, visto quanto è successo in passato, ma se volete usare quello strumento fate pure…

Infine, una nota per gli utenti che sono ancora rimasti ad edgy: ho trasferito la vecchia lista in un post con vecchia data; non manterrò più aggiorata quella lista, comunque se ci saranno segnalazioni commentate pure nel suddetto post.

CIAO! ^_^

PS: Oggi è anche uscita UbuntuStudio, pare davvero un bel progetto! Se molti tool già li conosciamo, la grafica pare davvero ben fatta!

Seppur non avessi ancora ufficializzato i miei repository, in realtà i dati si trovavano online da diverso tempo (dal 26 Aprile) ma visto che era ancora tutto in movimento preferivo non rendere la cosa completamente pubblica (anche se il front-end html già parlava chiaro); ad ogni modo ora penso sia giunto il momento di aggiornare la vostra lista dei repository con un po’ di pacchetti extra by Treviño :P, per farlo semplicemente aprite il vostro gestore di pacchetti o il file /etc/apt/sources.list e lì inserite le seguenti linee:

Quindi concedetemi la fiducia con: 

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

Come sempre è possibile spulciare il contenuto del repository attraverso questa pagina che contiene la lista di tutti i pacchetti con descrizione e link per scaricarli. Non so se l’avete notato, ma ormai da diversi mesi avevo aggiornato sia lo stile che il logo del front-end per renderlo conforme al blog ;).

Per segnalare eventuali problemi sia sui pacchetti che sul repository o per richiedere dei .deb, sapete come contattarmi (meglio per mail o irc)…

Colgo infine l’occasione per ricordarvi che a breve aprirò o integrerò anche altri repository per feisty (alcuni già usufruibili per i più “smaliziati”) con altro software sulla cresta dell’onda

Bye! ^_^ 

Ad ogni modo quando si trovano nella rete post come «trevino dov’è finito??!!» e si ricevono commenti, mail o messaggi IM chiedendomi che fine ho fatto diciamo che bisogna almeno far sentire la propria voce per dire che, ovviamente, ci sono sempre e come prima solo che ultimamente preferisco produrre (sia pur cose che magari non hanno un immediato utilizzo), piuttosto che fare “marketing”
Quindi state tranquilli che come dice qualcun altro, in altri ambienti ed ad altre persone: Treviño c’è!

Alla prossima!  

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!