1. un T61 con su windows xp, che serve solo come client di posta hardware e per completare burocrazia varia che richiede IE, e che in questo momento sta subendo un’installazione di Debian per un improbabile dual booting che non faccio dal novembre 1998

premessa: se devi usare la dimensione di un file come discriminante per decidere cosa farne, sei fottuto comunque; la prossima volta usa un nome decente. qualunque altra considerazione ricade sotto file management, e quello non lo fate da una finestra di dialogo che serve per aprire o salvare file, bensì da un file manager. ergo, non venitemi a menare il torrone con stronzate tipo “devo decidere cosa cancellare” oppure “devo vedere cosa spostare”: Nautilus ha già una colonna per le dimensioni quindi usate quello e non venite a rompere i coglioni a me.

nonostante la doverosa premessa, esiste un caso in cui effettivamente serve la dimensione dei file — ovvero quando devi aprire un file che non hai creato tu. dato che questo caso non dovrebbe essere l’unico modo in cui i file appaiono sul vostro computer¹, il default è “non visibile”.

dato che una sera mi annoiavo, e dato che la lettura dei commenti aveva provocato in me gli effetti noti, ho deciso di dedicare quei venti minuti necessari all’implementazione e il test².

quindi, ecco qui uno screenshot del selettore file con la colonna visibile:

la patch è già atterrata in trunk, quindi sarà nella prossima release, di qui a nove mesi circa.

quello che mi domando è: nei tre anni di vita di quel bug, e dopo venti commenti, è possibile che io sia stato il primo pirla ad avere venti minuti da spendere per:

• aprire un editor di testo
• trovare la parte che si occupa di leggere le informazioni sui file
• aggiungere numero una (1) colonna a un TreeView, numero uno (1) MenuItem, numero una (1) funzione di sorting

ora, vabbé che avevo venti minuti di totale odio per la razza umana, ma non è pensabile che io li abbia sempre e davanti a un computer con un check out delle GTK+³.

1. nel qual caso, lo porterei dal più vicino esorcista se fossi in voi
2. e non fosse che compilare le gtk+ su questo laptop porta via 10 minuti anche con due core, ci avrei messo meno
3. ah, ma chi prendo in giro: io ho sempre un check out delle GTK+

anche quest’anno, il GUADEC è stata una grande esperienza. ritrovare varia umanità con cui chiaccheri solo su IRC o su mailing list mette più o meno di buon umore — e se a questo si aggiunge passare la serata fino alle tre del mattino sdraiato su cuscini bevendo te e in compagnia di un nargilé al mango il quadro è completo.

al GUADEC, però, si va anche per parlare con persone che lavorano con e su GNOME — invariabilmente questo porta a interessanti sviluppi.

leggendo un po’ in giro, vedo che alcuni si sono scandalizzati o sorpresi del new deal nelle GTK+ e in GNOME; se però avessero seguito quello che avviene ogni giorno da un anno a questa parte si sarebbero velocemente resi conto di come tutto questo sia partito dallo scorso GUADEC — e possibilmente anche da quello prima. sigillare le GTK+ per poter cambiare gli internals senza rompere le applicazioni, ridurre il lasso di tempo da major release, non sono grandi e rivoluzionari piani: sono l’unico modo di portare avanti una piattaforma in maniera organica e continua. non vi siete svegliati una mattina trovandovi venti centimetri più alti, con una voce di due ottave più bassa e i caratteri sessuali secondari completamente sviluppati — vi ci saranno voluti anni. E se gestire la pubertà è un’impresa ardua, immaginatevi un desktop con milioni di utenti su varie piattaforme su cui non esercitate alcun controllo.

GNOME ha già provato a rompere con il passato in maniera netta, con un quantum leap invece che vari passi incrementali; è stato un diastro ferroviario, e sicuramente tutti quelli coinvolti nel progetto pensano "mai più". la somma di questi piani — GTK+ 3.0 e GNOME 3.0 — sono l’unica alternativa realistica.

se poi vogliamo andare sul non-realistico, possiamo sempre contare sull’aiuto di Babbo Natale e della Fatina dei Denti — ma ho i miei dubbi sull’implementabilità.

<div style="text-align:center"><h3>La Comunità di KDE</h3></div>

Ne danno <a href="http://dot.kde.org/1201517986/">il triste annuncio</a> la madre Trolltech e la sua nuova consorte, Nokia; gli utenti commerciali di Qtopia, che se producevano cellulari adesso si trovano costretti a cambiare piattaforma; gli utenti di KDE, per cui il desktop potrebbe finire in secondo piano quando l’unico provider monopolista della tecnologia su cui ti basi viene acquistato da un produttore di <em>embedded device</em> che intende usarti come anti-Android.

I funerali si terranno, in una data inevitabile a meno che qualcuno non tiri fuori 150 milioni di euro, a Helsinki.

<em style="font-size:75%">Certo però, che inculata pazzesca per gli utenti: prima la Trolltech forza la mano alla comunità per rilasciare un dimostratore incompleto e instabile di QT 4.x, poi vende l’ambaradan.</em>

Fuori di <em>obit joke</em>: questo succede quando tieni tutte le uova in un paniere, e ci fai pagare pure "la tassa" sopra, con tanto di benedizione di San Ignucius (a dimostrazione di quanto il buon Richard si stia rincoglionendo con l’età); se poi si guardano i <em>quarterly report</em> ci si accorge di come la Trolltech stesse perdendo <em>cash</em> dal 2006¹, e che erano appena riusciti ad arrivare a un netto tra <em>operative costs</em> e <em>operative revenues</em> nel Q3 2007. Non mi sorprende l’offerta di 100m di euro, quindi.
Adesso la palla passa alla comunità. Se la Nokia dovesse decidere in un cambio di strategia, KDE muore; se la comunità decide di forkare e rimanere sotto GPL (v3, <em>nonetheless</em>), KDE cessa di avere un <em>appeal</em> commerciale, e diventa il nuovo GNUstep.

1. Greenphone? Possibile.

Ho trovato dei difetti nel layer di traduzione, ma sono dovuti essenzialmente alla giovane età del progetto, e il team di sviluppo sta raccogliendo intorno a sé una quantità di collaboratori più o meno saltuari che fa ben sperare. In più, la mera esistenza di Vala sta spingendo a completare il supporto per l’introspezione in GObject².

Quello che più mi interessa, però, è la possibilità di avere un linguaggio a medio/alto ufficialmente sanzionato da GNOME – come Objective-C da Apple. Intendiamoci: la quantità di <em>binding</em> già presenti è enorme, e già oggi se volessi scrivere un’applicazione per GNOME potrei farlo in Perl, come in Java, come in C# e perfino con quel <em>train wreck</em> di Python³. Tuttavia, i bindings sono quello che sono: si portano dietro <em>virtual machine</em>, ambienti di <em>runtime</em>, licenze, implementazioni <em>patent encumbered</em> e altre amenità.

Intendiamoci: non ho nulla contro le <acronym title="Virtual Machine">VM</acronym> – a parte l’obiezione classica: "sto già usando una macchina virtuale su una macchina reale, perché devo usarne un’altra ancora per ogni linguaggio?"; tuttavia, e specie sulle macchine su cui lavoro, <strong>una</strong> <em>virtual machine</em> è già sufficiente – figuriamoci quattro o cinque. Mi piacerebbe che qualcuno prendesse Mono e ci portasse più di tre o quattro linguaggi; mi piacerebbe ancora di più che qualcuno prendesse <a href="http://en.wikipedia.org/wiki/Parrot_virtual_machine">Parrot</a> e lo completasse. Mi piacerebbe, insomma, avere <strong>una</strong> macchina virtuale per tutti i linguaggi ad alto livello. Se non posso averla, allora tanto vale usare Vala.

1. si potrebbe arguire come, in realtà, la VM usata sia il sistema operativo ospite, e che sicuramente esistono più piattaforme con un compilatore C che piattaforme che supportano Java o C#
2. ovvero la possibilità di avere meta-informazioni a <em>runtime</em> su una libreria, sulle API e sui tipi di dati esportati
3. che, spero, Python 3.0 affosserà definitivamente con tutte le modifiche arbitrarie alle API senza vere nuove <em>feature</em>; non ci resta, quindi, che sperare in IronPython per una implementazione sana di mente? non voglio pensarci

Oggi pomeriggio ho deciso di arrendermi e ho chiesto a Kris se poteva darmi una mano (dato che il <em>segfault</em> si verificava nel codice del <code>GtkTreeModelSort</code> che lui mantiene). Stasera mi dice di aver trovato la patch:

<pre>
Index: gtk/gtkfilechooserdefault.c
==============================================================
— gtk/gtkfilechooserdefault.c (revision 17846)
+++ gtk/gtkfilechooserdefault.c (revision 17848)
@@ -9508,7 +9508,7 @@ recent_column_path_sort_func (GtkTreeMod
if (!name_a)
return 1;

- if (!name_b);
+ if (!name_b)
return -1;

if (is_folder_a != is_folder_b)
</pre>

Penso che i miei moccoli siano arrivati vicinissimi al Moccolo a Delta di Dirac (dieci alla ventottesima madonne in un microsecondo).

<em>Va da sé che Kris si vedrà offrire una birra al GUADEC.</em>

<h4>GTK+</h4>

Per mancanza di tempo, negli ultimi mesi ho dovuto lasciare a metà alcuni miei lavori sulle <a href="http://www.gtk.org">GTK+</a>. Fortunatamente ogni tanto si è aperto qualche spiraglio di tempo libero, e quando ho potuto ritornare alla libreria che (ricordiamolo) ha consentito all’avere di che mangiare non mi sono certo fatto scrupoli.

Le GTK+ sono piagate, da tempo ormai, da una cronica mancanza di sviluppatori nel <em>core team</em>; il flusso di patch in <a href="http://bugzilla.gnome.org">Bugzilla</a> è più o meno costante (anche se non altissimo), ma le persone in grado di fare una revisione delle patch e in generale dei bug segnalati sono poche, e nessuno lavora a tempo pieno sulle GTK+. A questo si aggiunge un’inerzia proveniente dalle compagnie che lavorano con le GTK+ nei confronti di una (ormai inevitabile) rottura della compatibilità binaria e, possibilmente, delle <acronym title="Application Programming Interface">API</acronym>. Il quadro è complesso, e meriterebbe un post di analisi dei fattori pro e contro una tale rottura di compatibilità all’indietro; sfortunatamente è sabato mattina e non ho molta voglia di farlo – considerate la questione solo rimandata.

Cosa si muove, quindi, nelle GTK+? Cosa ci sarà nella prossima <em>minor release</em>, la 2.12.0? E cosa ci aspetta nel futuro?

Cominciamo con le cose già in <code>trunk</code>:

<dl>
<dt><strong>Supporto Quartz e DirectFB</strong></dt>
<dd>Il lavoro sui backend per GDK continua; il backend per Quartz è mantenuto dagli sviluppatori della Imendio ed è quasi stabile; mancano ancora feature, e molto dipende dalla stabilità del backend Quartz di Cairo, ma comincia ad essere usabile. Il backend DirectFB è invece portato avanti dal team per l’installer grafico della Debian, e ha ricevuto molte attenzioni in occasione del rilascio di Etch. Alcune delle funzionalità sono state aggiunte alla branch stabile, ma <code>trunk</code> è il posto dove la magia avviene.</dd>

<dt><strong>Rimosso il supporto a Windows 9x/ME</strong></dt>
<dd>Il supporto per i sistemi operativi giocattolo della casa di Redmond era già cessato con la release 2.10; adesso è stato completamente rimosso dalla <em>code base</em>. Chi vuole, può fare un <code>diff</code> tra 2.10 e <code>trunk</code>, procurarsi un incudine e un martello e prepararsi per un’intensa sessione di martellate sui gioielli di famiglia.</dd>

<dt><strong>Nuova API per le tooltip</strong></dt>
<dd>Kristian Reitveld ha creato una nuova API per gestire le tooltip sui vari widget. D’ora in poi, niente più <code>GtkTooltips</code> da tenere in giro per tutta la durata dell’applicazione, ma una semplice proprietà che contiene il testo della tooltip (con supporto per il markup). Se si vuole modificare la finestra stessa usata per la tooltip, basta fare l’<em>override</em> di una funzione virtuale della class <code>GtkWidget</code> e si può usare la finestra che si preferisce. Questo, tra l’altro, permette finalmente di poter usare tooltip con <code>GtkTreeView</code> e <code>GtkComboBox</code>.</dd>

<dt><strong>File recenti</strong></dt>
<dd>Una delle cose che ho scritto io. Finalmente è possibile infilare la lista dei file recenti in un menu costruito usando <code>GtkUIManager</code>. Per la disperazione (di uno) degli autori di <a href="http://www.gnome.org/projects/gedit">gedit</a>, niente menu "in linea" (come Windows, per intenderci) ma solo come sotto-menu (come OS X). Scrievere una version in linea non è complicato (se volete, trovate una implementazione <a href="http://www.gnome.org/~ebassi/recent-uimanager-inline.c">qui</a>). Ho anche aggiunto la possibilità di inserire elementi del menu prima e dopo la lista dei file recenti nel <code>GtkRecentChooserMenu</code>, così da renderlo più simile a un <code>GtkMenu</code> (quale è).</dd>

<dt><strong>FileChooser migliorato</strong></dt>
<dd>Una delle cose che mi fanno aumentare la misantropia e, in generale, il desiderio di vedere la razza umana estinguersi sono le <em>flame</em> sul selettore di file delle GTK+. Seriamente: ogniqualvolta arriva qualche sedicente esperto di usabilità che urla ai quattro venti come il <code>GtkFileChooserDialog</code> sia "inusabile" io spero solo che si tratti di qualcuno che vive vicino ad una costa marittima, e aspetto che il riscaldamento globale faccia il resto. Due settimane fa ho fatto il <em>commit</em> della patch (non scritta da me) che aggiungeva il supporto per la ricerca di file usando (indirettamente) Beagle, Tracker o una semplice ricerca per nome. La patch aveva ancora dei problemi, con funzionalità non implementate o comportamenti non consistenti, quindi ho passato questa settimana a scrivere <a href="http://www.gnome.org/~ebassi/filechooser-merge/">patch</a> per chiudere il bug <a href="http://bugzilla.gnome.org/show_bug.cgi?id=435343">#435343</a> e intanto che c’ero anche il bug <a href="http://bugzilla.gnome.org/show_bug.cgi?id=435342">#435342</a> (se volete vedere come appare il selettore file adesso, ci sono degli screenshot <a href="http://www.gnome.org/~ebassi/filechooser-recent.png">qui</a> e <a href="http://www.gnome.org/~ebassi/filechooser-search.png">qui</a>) per aggiungere la lista dei file recenti direttamente nel selettore di file e chiudere così integrazione iniziata con la scorsa versione delle GTK+ – quasi due anni dopo il <a href="http://www.emmanuelebassi.net/archives/2005/05/guadec-live/">GUADEC che ha iniziato tutto quanto</a>.</dd>

</dl>

Ovviamente, le novità non sono solo queste. C’è stato un gran lavoro nel portare alcune <em>feature</em> sviluppate per piattaforme <em>embedded</em>, come la navigazione via tasti oppure il metodo di inserimento per tastiere solo numeriche. In più, ci sono nuove <em>feature</em> in fase di valutazione e di revisione che non sono ancora "atterrate" in <code>trunk</code>, come il supporto per il <em>tap-and-hold</em> per i menu contestuali (usato dai <em>touchscreen</em> o più in generale da chi ha puntatori con un tasto solo, come Mac o <em>tablet</em>). Infine, c’è la grossa <em>feature</em> rappresentata dal <code>GtkBuilder</code>, ovvero la possibilità di creare interfacce utente usando XML – come libglade ma integrato ed esteso.

Cosa ci attende nel post-2.12 non si sa. Le GTK+ avranno finalmente un canvas? E come impatterà questo oggetto con la struttura dei widget? In più, avremo finalmente una class <code>GtkApplication</code> per scrivere applicazioni in maniera più semplice, lasciando che siano le GTK+ a gestire le sessioni e lo stato (liberandoci di un bel pezzo di <code>libgnome</code> e <code>libgnomeui</code>)? Avremo un <em>layer</em> per <acronym title="Virtual File System">VFS</acronym> finalmente usabile senza una lobotomia parziale? E una piattaforma per la configurazione che non sia ferma al 2001?

Infine, quando avremo le GTK+ 3.0, con una ripulitura generale del codice?

Non so dare risposte; so solo che chi vivrà, vedrà.

<em style="font-size:80%">continua…</em>

Sul fronte più interessante dell’hacking, sto finendo la riscrittura di <code>gnome-screenshot</code>; ho rimpiazzato buona parte del codice con oggetti, rimosso l’uso diretto delle Xlibs in favore delle più compatte e utili GDK (tagliano circa l’80% di fuffa, garantendomi una certa qual sanità mentale), e aggiunto il <em>code path</em> per scattare screenshot su compiz/beryl/vattelapesca (che <strong>non</strong> fanno il <em>reparenting</em> delle finestre con il <em>frame</em> aggiunto dal window manager – come chiunque abbia tentato di usare gnome-screenshot sotto compiz avrà notato).

Un altro fronte sul quale ho lavorato nelle ultime due settimane è stata la separazione di <em>backend</em> in <a href="http://www.clutter-project.org">Clutter</a>; adesso Clutter si può usare sia in ambienti desktop con GL che in ambienti embedded con GL-ES; in più, il codice è molto migliorato e la gestione degli eventi pure.

Infine, qualche tempo fa ho incontrato <a href="http://njpatel.blogspot.com/">Neil Patel</a> dal vivo. Trattasi di ragazzo particolarmente in gamba impegnato nella realizzazione di <em>bling</em> vario e utile per il desktop. A quanto pare, si è interessato a Clutter per scrivere una specie di <em>media center</em>. Il suo unico difetto è che gli piace Tracker, ma non temete: con un po’ di convincimento da parte del sottoscritto potrebbe lasciar perdere quell’aggeggio senza speranze.

<blockquote>
Gli utenti si apettano tutte le funzionalità del file manager dalla finestra di dialogo per salvare un file [...] quindi se Nautilus è installato le GTK+ dovrebbero eseguire Nautilus [al posto della GtkFileChooserDialog].
</blockquote>

Sicuramente, ha a che fare con della droga – <em>crack</em>, nel caso specifico. Lasciamo perdere l’evidente caso di inversione (perché le GTK+, che sono un toolkit multipiattaforma, dovrebbero dipendere da Nautilus, <em>albeit</em> opzionalmente?), e concentriamoci sull’idiozia di poter effettivamente modificare file, directory ed eseguire applicazioni <strong>mentre si sta salvando un file</strong>. Ottimo se hai un <em>attention deficit disorder</em> e non riesci a fare a meno di lavarti i denti mentre bevi il caffé, tirandoti su i pantaloni alla fermata dell’autobus.

Oppure no.

<div style="text-align:center">
<a id="p1052" rel="attachment" class="imagelink" href="http://www.emmanuelebassi.net/archives/2007/03/give-it-up/amarok-2png/" title="amarok-2.png"><img id="image1052" src="http://www.emmanuelebassi.net/wp-content/amarok-2.png" alt="amarok-2.png" /></a>
</div>

Se verrete catturati, uccisi oppure vi butterete dalla finestra dall’orrore, il dipartimento negherà di essere a conoscenza della vostra missione.

Poi, a che diavolo serve il menu <em>Engage</em>? Cos’è, l’Enterprise?

Le motivazioni per utilizzare Amarok stanno scivolando sempre più verso il lombrosiano.