On the other side of the screen, it all looks so easy

Archive for hacking

Travelling without moving/End

l’ultima tappa si è conclusa ieri.

la settimana berlinese è stata decisamente interessante. tra le cose importanti:

  • Clutter viene ormai visto1 come il candidato per il posto di GtkCanvas
  • aggiungere il supporto per GL in GDK, e altre feature a Cairo per permettere di usare le schede grafiche in maniera migliore, sono sicuramente nei piani — speriamo di avere qualcosa di pronto per il GUADEC
  • Berlino è sempre una città straordinaria

per inciso, sono riuscito a tornare nella stessa zona visitata due anni fa, e sebbene Berlino cambi così velocemente, e così tanto, e così in meglio in poco tempo, mi ha fatto piacere ritrovare alcuni luoghi esattamente come li avevo lasciati.

infine, ho scoperto il segreto della produttività: tre ore in un coffee shop senza connettività; mai scritto codice tanto velocemente.

  1. con ragione, ma lo dico come sviluppatore, non come maintainer []

Comments (3)

Driving Sideways

non ti rendi conto di quanto dai per scontato in Linux se non quando devi replicare un ambiente di sviluppo sotto OS X. fortunatamente, con un po’ di Macports e di JHBuild si riesce a mettere in piedi qualcosa di usabile.

una cosa sicuramente mi piacerebbe avere anche sotto GLX, e sono i tool per fare profiling delle chiamate OpenGL; l’UI è banale da replicare (basta prendere una cosa tipo questa) ma quello che è interessante è tutta la serie di hooks per attaccarci uno statistical profiler.

Comments

Going Mobile/2

Dal FOSDEM. Più precisamente: dalla GNOME dev room del FOSDEM, una volta tanto che la connessione funziona.

Parrà incredibile, ma le conferenze di hacker, programmatori e più in generale smanettoni, hanno la peggior connettività del mondo; forse è perché tutti i partecipanti hanno almeno un computer acceso e in procinto di fare un sync con venti repository

Nel frattempo, uno screenshot di quello su cui sto lavorando:

Places in the file chooser
Directory speciali nel file chooser, caricate da un file esterno e traducibili.

Ovvero, l’implementazione di DesktopPlaces.

Comments (7)

Nuclear War (On The Dance Floor)

Di solito non accendo flame: ci partecipo solo (grazie ai poteri della I-can-t-believe-it-s-not-Asbestos tuta che mi è servita per anni su Usenet) perché mi diverte vedere le buffe reazioni degli esseri umani (misantropo umanista? You bet!).

Stavolta, però, me la stanno tirando fuori dalle carni.

Chiunque segua desktop-devel-list sarà al corrente che non nutro grande simpatia per Tracker, il calderone di indexer/database/interfaccia grafica/kitchen sink/quello che sarà questa settimana che alcuni vorrebbero avere una maggiore integrazione con GNOME.

Premetto subito che io non odio Tracker: mi stanno cordialmente sulle balle le modalità con cui viene evangelizzato e, soprattutto, sviluppato. Dopo un anno e rotti in cui è stato riscritto almeno tre volte, cambiato il database, cambiato l’indexer, aggiunte feature e realizzato poco testing, ancora manca una cazzo di API decente per permettere a me, sviluppatore, di poterlo utilizzare. Si, perché il fine ultimo di Tracker è, evidentemente, immagazzinare il maggior numero di informazioni sui vostri file e poi non utilizzarle, dato che esiste solo una serie di remote procedure calls per D-Bus e nient’altro. Ma certo, se ho bisogno di estrarre dati mi basta usare Python. Solo che non io posso riscrivere GNOME in Python (o C++, o C#, o D, o COBOL o ${WHATEVER_LANGUAGE_ZEALOTS_WILL_PROPOSE_NEXT} - in fondo, abbiamo milioni di linee di codice da riscrivere da capo, che sarà mai), e gli utenti non hanno un cazzo di Cray su cui far girare uno GNOME scritto in Python (i requisiti di memoria dopo otto ore di utilizzo sono quelli). By the way: menarmi il torrone su quanto Tracker sia buono con la mia CPU e la mia RAM e poi dirmi che se voglio usarlo devo ridurmi a scrivere un’applicazione in Python è prendermi per culo - puro e semplice; e io non sopporto quando mi prendono per il culo.

Prendiamo HAL, l’Hardware Abstraction layer scritto per evitare di dover pasticciare con device, permessi e stronzate varie; è composto da RPC ma ha anche ben due librerie che mi permettono di non dover usare D-Bus direttamente. Perché? Perché HAL è scritto da qualcuno sano di mente, probabilmente, che pensa che l’utente non se ne fa una sega di HAL in quanto tale - l’utente è esposto ad applicazioni che usano HAL a loro volta; gli utenti di HAL sono gli sviluppatori, e se non do agli sviluppatori un’API sensata come diavolo faranno a scrivere applicazioni? Tracker occupa una nicchia analoga: gli utenti non sanno cosa sia Tracker, a cosa serva o come lo faccia; sanno solo che possono aggiungere una tag a un file e cercare file usando lo stesso tag. Se un utente si eccita con il fatto che esista Tracker è un cazzo di geek, e non è per loro che io contribuisco a GNOME.

Quindi, prego qualcuno di mettersi a scrivere un’API coi contro cazzi per permettermi di scrivere applicazioni con Tracker; non widget: voglio scrivermi i miei widget senza aspettare sei mesi che qualcuno ne aggiunga uno che mi serve. Perché sono io che scrivo applicazioni per GNOME, non “gli utenti”; e se io non sono in grado di scrivere applicazioni per GNOME usando Tracker vorrà dire che sarò costretto a reinventarlo tra sei mesi.

Giuro, mi basta qualcosa che mi dia un GObject a cui far eseguire un match, e abbia segnali che mi dicono cosa la mia richiesta ha trovato. Perché non c’è ancora? Perché gli sviluppatori e chi contribuisce a Tracker ha deciso di perdere il suo tempo per scrivere front-end per la Deskbar applet, mantenere branch parallele di Nautilus e violentare il Search Tool invece di permettere ai maintainer di questi progetti di fare il loro lavoro?

</rant>

Comments (8)

Overdrive/1

Un recap sui progetti a cui sto lavorando al momento.

Clutter

Nei commenti al blog precendente mi si chiedeva di Clutter. Per chi non seguisse Planet GNOME (o per chi lo seguisse ma non avesse comunque la più pallida idea di cosa si tratti), Clutter è un toolkit che ho contribuito a realizzare più o meno da quando sono stato assunto alla OpenedHand (settimana più, settimana meno).

Clutter è un toolkit basato sulle stesse librerie usate per le GTK+ (GLib, GObject, Pango) ideato per scrivere applicazioni con un’interfaccia grafica mono-finestra - ad esempio: media box, personal video recorder, etc. - in ambienti (embedded e non) dotati di grafica accelerata (tramite OpenGL oppure OpenGL ES). Clutter fornisce un canvas, rappresentato dal singleton ClutterStage, e alcuni widget, chiamati ClutterActor. I widget forniti sono (volutamente, al momento) pochi: non solo perché siamo alla release 0.2.0, ma soprattutto perché vogliamo vedere di cosa necessitano gli sviluppatori prima di implementare ClutterActor nel modo sbagliato o del tutto inutili.

Hello, World - Come funziona Clutter? Ecco un semplice “hello, world” che sfrutta buona parte delle nuove API. È scritto in Python - avrei preferito scriverlo in Perl, ma conoscendo la quantità di pythonisti in “ascolto” ho scelto altrimenti; la versione in Perl è disponibile a richiesta. Se volete, potete scaricarla e farci quello che volete - è nel public domain, come dovrebbero essere tutti gli “hello world” di questo mondo. Se cliccate dopo il link, smonto il codice in blocchi per spiegare come funziona.

Read the rest of this entry »

Comments (16)

Problem solving without solving problems

Ikitt, su autopackage (in particolare, penso si riferisca a questa pagina.

Il vero problema di autopackage non è l’attitudine dei programmatori di autopackage - in fondo, progetti F/OSS portati avanti da persone che non riescono a comportarsi come degli adulti razionali ne abbiamo avuti e ne avremo ancora; pensiamo a MPlayer: nato male, portato avanti con arroganza e spocchia, sta finalmente per finire nel dimenticatoio, sorpassato da soluzioni tecnicamente superiori e sviluppate da gente che, almeno, non dice che tutto il resto fa schifo. Questo perché MPlayer copriva una nicchia nell’ecosistema del free software che doveva essere coperta.

Autopackage, al contrario, non risponde ad alcuna esigenza vera e propria, se non al bisogno di alcuni sviluppatori per Windows (che non hanno ancora capito come funzionano le cose sotto *nix e Linux) di avere un unico pacchetto da installare su tutte le macchine che hanno sotto mano. È un’esigenza sentita da qualcuno? Si - ovviamente. È un’esigenza rilevante? No, altrettanto ovviamente. Altrimenti avremmo molti altri progetti simili ad autopackage - mentre l’unico che mi viene in mente è Klik, ovvero un altra soluzione messa a punto da e per programmatori per Windows.

Secondo gli sviluppatori di autopackage l’onere di far funzionare il proprio software con tutte le distribuzioni dovrebbe ricadere sugli sviluppatori delle applicazioni; questo non solo è dimostrabilmente inutile, ma pure dannoso. Io uso Ubuntu e conosco il sistema di pacchettizzazione della Debian a sufficienza per poter fare pacchetti .deb; tuttavia, uno sviluppatore Debian che abbia finito la NM ne sa indiscutibilmente più di me riguardo alle policy della Debian; stesso discorso vale per pacchetti RPM e per uno sviluppatore della Fedora Core 5. Anche se quelli di autopackage mi forniscono un’API per astrarmi dal lavoro pesante di aver ca che fare con relocation di librerie e binari, le minutie del package management non le posso (e non le voglio) imparare. In più, a meno di non ricorrere alla Fatina dai Capelli Turchini, e di sostituire tutto l’installato planetario con pacchetti basati su Autopackage in un microsecondo, avremo sempre a che fare con pacchetti autopackage che rompono inesorabilmente i pacchetti legittimi delle distribuzioni.

Quindi, il vero e serio problema di autopackage è la completa inutilità del fine prefisso (”un solo package manament system per tutte le distribuzioni gestito dagli sviluppatori stessi”); a questo si deve aggiungere una ignoranza di base sui meccanismi delle distribuzioni e dei loro package manager; poi, ma solo alla fine, una manifesta arroganza da “noi abbiamo la soluzione per tutti i vostri problemi, e tutti gli altri sono solo dei perfetti stronzi”, che fa risultare gli sviluppatori di autopackage automaticamente dalla parte del torto.

Comments (4)

Leaving on a jet plane

L’aereo per Bruxelles è tra otto ore e qualcosa.

Il bus per l’aereoporto è tra cinque ore e mezza.

Dati gli orari di arrivo, è certo che mi perderò il keynote di Stallman. Me ne faccio rapidamente una ragione.

La valigia è pronta, il portatile pure.

Ci si risente martedì - ma se riesco a rimettere a posto la scheda wi-fi, anche prima.

Comments (3)

Include

Da un paio di giorni è stato incluso nelle GTK un piccolo widget da me scritto, GtkLinkButton; niente di particolare, solo un bottone associato a una URL e con uno stile “link” (blu, sottolineato). Insomma, un contributo molto modesto da parte del sottoscritto.

È, a tutti gli effetti e scopi, un altro chiodo nella bara di libgnomeui - una delle librerie che verranno rese obsolete dalla versione 3.0 delle GTK (nome in codice: Project Ridley) e dall’equivalente release di GNOME (nome in codice: Topaz).

Tutto questo in attesa che il mio contributo più consistente, l’aggeggio per i file recenti, venga sottoposto a revisione e incluso prima della release 2.10 delle GTK (prevista per questa estate).

Comments

Release Night

Ieri sera dovevo fare la release di gnome-utils. Dopo averla fatta, ho fatto pure la release di gnome-terminal, dato che il (nuovo) maintainer doveva uscire e non avrebbe avuto tempo materiale di farla (le release devono essere fatte in un giorno prestabilito all’inizio del ciclo di sviluppo, entro un’ora prestabilita).

In un attimo di follia, ho anche accettato di fare una release di emergenza di altri tre pacchetti - i fondamentali libgnome, libbonoboui e libgnomeui. Questo a due ore dalla scadenza del termine.

Divertito, mi sono divertito. Ma è stata una follia che desidererei non rifare - almeno, non per i prossimi sei mesi.

Apropòs: se usate Ubuntu Dapper (6.04), aggiornate domani o dopo; c’è stato un lieve cambiamento nelle API di libgnome, e i pacchetti che fanno uso della classe GnomeProgram devono essere ricompilati contro le nuove release di libgnome, libbonoboui e libgnomeui, altrimenti si rompono in maniera abbastanza spettacolare.

Comments (4)