conundrum

Per un Falwell che (mai troppo presto) <a href="http://www.baltimoresun.com/news/bal-falwell0515,0,7560428.story?track=mostviewedlink">ci lascia</a>, un Betori che <a href="http://www.repubblica.it/2007/04/sezioni/politica/cei/betori-sessi/betori-sessi.html">rimane</a>. A quanto pare, non solo la natura non aborre il vuoto (pneumatico) ma ci sguazza.

Ho passato gli ultimi tre giorni a tentare di capire perché un pezzo di codice producesse un <code>SIGSEGV</code>. Ho cambiato linee, logica, tipi di dato. Niente: qualunque cosa facessi, solo crash. Come al solito, <code>gdb</code> si rivelava poco utile, mentendo spudoratamente sul luogo della violazione di memoria.

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>

In questi due giorni mi chiedo, a mo di esercizio puramente intellettuale, perché la Turchia non sia già in Europa…

<div style="text-align:center"><a class="imagelink" href="http://www.emmanuelebassi.net/wp-content/turchia-laica.png" title="Turchia laica?"><img id="image1061" src="http://www.emmanuelebassi.net/wp-content/turchia-laica.png" alt="Turchia laica?" /></a></div>

… e perché, al contrario, ci sia l’Italia…

<div style="text-align:center"><a class="imagelink" href="http://www.emmanuelebassi.net/wp-content/italia-non-laica.png" title="Italia non laica?"><img id="image1062" src="http://www.emmanuelebassi.net/wp-content/italia-non-laica.png" alt="Italia non laica?" /></a></div>

<em style="font-size:80%"><a href="http://www.emmanuelebassi.net/archives/2007/01/overdrive1/">segue</a></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>

Solo una breve riapparizione su questi schermi (il lavoro è tiranno, e non succedono cose interessanti per il sottoscritto in questo periodo – a parte il viaggetto in quel di Copenhagen per il Nordic Perl Workshop), per la questione dei <a href="http://www.macchianera.net/2007/05/03/09_f9_11_02_9d_74_e3_5b_d8_41.html">numeri</a> che rappresentano una delle chiavi di decrittazione dei dischi HD-DVD. Non è una questione di copyright di numeri: nessuno ha registrato una sequenza di numeri come <em>trade mark</em>, nessuno sta usando le <em>copyright laws</em> per impedire alla gente di scrivere quei numeri in giro per la blogsfera perché <strong>i numeri stessi</strong> sono un copyright. La legge che le compagnie che producono i sistemi di crittazione per HD-DVD stanno tentando di usare per bloccare i numeri è il <em><a href="http://en.wikipedia.org/wiki/DMCA">Digital Millenium Copyright Act</a></em> – ovvero stanno tentando di bloccare chi pubblica quei numeri perché l’unico modo per ottenerli è violare il copyright <strong>del meccanismo di cifratura</strong>.

Come sempre, in questi casi, il telefono senza fili risulta in informazione al ribasso.

<em>Poi, va da sé: un sistema di cifratura che prevede una chiave infilata in ogni pezzo di software e hardware venduto è automaticamente destinato a fallire; l’industra degli audiovisivi è troppo stupida per capirlo e piantarla di usare questi mezzucci, mentre l’industria che produce sistemi di cifratura è troppo furba per dirlo in giro e semplicemente sparire tra le pieghe della storia del capitalismo.</em>