Ci ho le prove

Il comune di Roma, la regione Lazio e l'Atac (no, non l'Associazione Teologica Amici Cristo, ma l'Agenzia per la Mobilità del Comune di Roma - che diventerebbe AMCR, ma nessuno più capirebbe di chi si parla) hanno per il secondo anno concordato la possibilità agli anziani "over 70" con reddito "under 15000" di usufruire gratis del trasporto pubblico.

Ora, non starò qui a polemizzare per il fatto che i candidi vecchiettini, specie avendo la cosa gratis, finiscono con l'occupare stabilmente i mezzi di trasporto pubblici, specie negli orari in cui la gente va a scuola o al lavoro, congestionando così le banchine e gli interni di metropolitane e autobus. Non è giusto parlare male di persone che hanno vissuto fascimo e seconda guerra mondiale senza che ciò li abbiano fatti diventare un po' più tolleranti nei confronti dei giovani che non hanno vissuto eventi di simile portata storica. Quindi non dirò che francamente rompono un po' i coglioni quando la mattina spingono a forza per entrare - perché la saggezza popolare e le sofferenze patite in gioventù dice loro che avanti c'è posto - in un autobus che li porti a fare qualche visita alle 8.15 del mattino - la paura giornaliera di morire prima di pranzo li porta a rifiutare orari come le 10.45 o (dionescampi) 11.30 -. No, non lo dirò perchè è altro ciò di cui voglio riferire.

Per poter usufruire dei trasporti gratis bisogna quest'anno presentare un'autocertificazione con la quale farsi rilasciare una tessera. Orbene non solo il modulo è disponibile sul web, non solo è scaricabile in formato PDF ma - le mani mi tremano a scrivere, quasi non riesco a premere bene i tasti, ma forse è colpa della tastiera "natural" a cui non sono abituato... - il file PDF è stato generato usando OpenOffice.org Writer!!

Se proprio volete le prove:

Doppia coppia

Un esperimento mai tentato prima da mente umana: ecco a voi uno strabiliante post che si occuperà di due (2) argomenti e in entrambi gli argomenti ci saranno due "cose" da confrontare o considerare.

Icone e pixel

Risolto nella versione di sviluppo di GNOME il problema relativo all'errata visualizzazione delle icone a 24 pixel (che è un multiplo di 2!). L'immagine era infatti presa tra quelle a 22 pixel (che non solo è un multiplo di 2, ma è anche 24-2!!).

La cosa strabiliante è che la risoluzione è doppia: bug #395830 e bug #343437. Nel primo si è cambiato l'algoritmo di lookup delle icone nelle GTK+ (legato a problemi di precedenza che non vi sto a riportare che si sono evidenziati dopo il passaggio dalla icone 24x24 pixel a quelle a 22x22 pixel); nel secondo si è cambiata la dimensione predefinita delle icone usate nel menù Applicazioni del pannello (da 24 a 22) in modo da evitare i pixel vuoti aggiunti per creare le icone a 24 e in modo da essere più simpatici con le applicazioni per KDE, che usano da tempo immemore le icone a 22, e si è forzato l'uso delle sole dimensioni definite da Tango (12, 22, 32 e 48).

Epson vs HP

L'annoso dibattito tra marche di stampanti è tornato a farsi vivo anche in casa mia. L'attuale stampante, una Epson Stylus CX3650 (che, guarda caso, è una multifunzione, stampante e scanner... di nuovo il due, accidenti!!!!) ha praticamente tirato le cuoia.

La testina di stampa è ormai andata: ostruiti i canali del magenta e del ciano, in modi che misteriosamente neanche un bagno nel cleaner è riuscito a liberare, ho rosicchiato qualche mese di vita stampando solo in biano e nero. Ora, senza che nessuno l'abbia usata, la cartuccia del giallo dice di essere scarica (lo so, l'inchiostro c'è, ma è il fottuto chiop a dire il contrario). L'ipotesi "compro una cartuccia scrausa per il giallo e tiro avanti un altro po'" andrebbe a cozzare con la riflessione "le cartucce del ciano e del magenta hanno praticamente la stessa vita e tra un po' manderanno gli stessi messaggi".

Quindi, come ogni consumatore che si rispetti, è giunto il momento del cambio stampante!

Ora, visto che le principali magagne della Epson le conosco già (chip sulla cartuccia che conta i movimenti della testina e non il reale livello di riempimento, testina di stampa esterna alla cartuccia che se si ostruisce per bene butti via tutto.. ehi, sono due anche queste!!!!!), visto che la politica dei driver Canon non soddisfa le aspirazioni open source, visto che della Lexmark so ben poco, che si dice nella noosfera delle stampanti a getto d'inchostro HP?

La mia sorellina ha già evidenziato due (ancora!!!!!!!) problemi: necessità di allineare le testine di stampa a ogni cambio cartuccia (però le testine sono inglobate nella cartuccia, che costa di più, ma salva dalle ostruzioni) e durata irrisora dell'inchiostro (dipende forse dal fatto che c'è una cartuccia per 3 colori?).

Certo, la stampante perfetta non esiste, lo so. Magari si può essere fortunati, scegliere un modello costruito con un po' di sale in zucca, prendere dal mucchio quella che non è stata sbattuta troppo nel trasporto. Ma dalla maledizione del cambio cartuccia credo ci si possa salvare difficilmente.

A proposito

A proposito della ricorrenza quasi esoterica del numero 2 in questi bug report (oltre a quanto già notato, 395830 è divisibil e per 2, mentre 343437 contiene una ripetizione del 34!!!!), faccio mie le antiche parole di uno sconosicuto alchimista empirico del XIV secolo: «Ma guarda un po'».

Colori, colori, colori - un approfondimento

A voi, maniaci dei temi che siete lì fuori. Voi che non riuscite a tenere lo stesso aspetto grafico per più di una settimana (e a volte anche meno). Ascoltate.

Partiamo dall'alto, dallo strumento di preferenze Tema del centro di controllo di GNOME. Nella versione in corso di sviluppo, questo strumento è in grado di riconoscere sei colori simbolici:

• fg_color
• bg_color
• text_color
• base_color
• selected_fg_color
• selected_bg_color

Le prime due coppie corrispondono a ciò che di solito viene impostato come colori base del tema (sfondo e primo piano di widget semplici e sfondo e primo piano di widget "di testo" come le GtkEntry). La terza coppia indica i colori nello stato selezionato (per esempio quando evidenziate una voce di menù).

Cosa vuol dire riconoscere? Banalmente significa che se nella definizione del tema (file gtkrc) sono stati usati i nomi simbolici precedentemene elencati, se è in esecuzione il demone delle impostazioni di GNOME (gnome-settings-daemon) e se sono stati scelti dei colori personalizzati, allora all'atto della rappresentazione a schermo, il colore definito nel file gtkrc viene scartato in favore del colore scelto nei dettagli dello strumento di preferenze.

Dunque, per poter ricolorare un tema è necessario che il tema sia stato scritto sfruttando questi sei colori simbolici. Non c'è alcuna necessità per motore del tema di supportare alcuna particolare funzionalità. Tutto il lavoro è svolto dalle GTK+ e dalla definizione del tema, tramite semplice associazioni widget->stile->colore.

Nota: sì, il sistema di gestione dei temi delle GTK+ è abbastanza complicato e si divide tra motori dei temi (theme engine - contengono il codice per il tracciamento delle forme) e file di definizione (gtkrc - contengono una serie coppie proprietà=valore per i widget dell'interfaccia, widget per widget o gruppo per gruppo). Cercherò di non entrare troppo in dettaglio.

A questo punto dovrebbe però essere sorto un dubbio: come è possibile scrivere una definizione di tema esteticamente gradevole usando solo 6 colori? Sfruttando una proprietà delle GTK+ 2.10 che permettono di creare un nuovo colore variando un colore esistente, tramite le espressioni mix(fattore, colore1, colore2) e shade(fattore, colore). Sono anche disponibili darker(colore) e lighter(colore) che altro non sono che shade con fattore preimpostato.

Per ogni ulteriore informazione o approfondimento, consultate la spiegazione sui file di risorsa delle GTK+.

Passiamo ad un esempio pratico: scriviamo un semplice file gtkrc per un tema ricolorabile.

Ogni tema presenta almeno una sezione in cui si definisce uno stile

style "default"
{
fg[NORMAL]        = @fg_color
fg[PRELIGHT]      = @fg_color
fg[SELECTED]      = @selected_fg_color
fg[ACTIVE]        = @fg_color
fg[INSENSITIVE]   = darker (@bg_color)

bg[NORMAL]        = @bg_colo
bg[PRELIGHT]      = shade (1.02, @bg_color)
bg[SELECTED]      = @selected_bg_color
bg[INSENSITIVE]   = @bg_color
bg[ACTIVE]        = shade (0.9, @bg_color)

base[NORMAL]      = @base_color
base[PRELIGHT]    = shade (0.95, @bg_color)
base[ACTIVE]      = shade (0.9, @selected_bg_color)
base[SELECTED]    = @selected_bg_color
base[INSENSITIVE] = @bg_color

text[NORMAL]      = @text_color
text[PRELIGHT]    = @text_color
text[ACTIVE]      = @selected_fg_color
text[SELECTED]    = @selected_fg_color
text[INSENSITIVE] = darker (@bg_color)

engine "clearlooks"
{
 menubarstyle  = 2
 animation     = TRUE
 radius        = 4.5
 style         = GLOSSY
}
}

Ho volontariamente omesso ogni definizione di proprietà dei singoli widget (cose come GtkScrollbar::min_slider_length = 20 per definire la dimensione minima del cursore delle barre di scorrimento): sebbene non siano essenziali per questa discussione, influiscono fortemente nell'aspetto grafico finale di un tema, andando a modificare le dimensioni e le spaziature dei vari componenti.

Sono solo presenti, nella definizione di questo stile, le definizioni dei colori da usare (di nuovo, consultate la pagina linkata prima per capire il significato delle varie opzioni) usando colori nominali riconosciuto dallo strumento di preferenze Tema e espressioni di modifica fornite da GTK+ (2.10 e successive) e la definizione del motore di tema da usare con le opzioni riconosciute da questo.

Uno stile deve poi essere applicato a un widget o a un gruppo di widget. Visto che stiamo facendo una prova, lo applichiamo indifferentemente a tutti i widget. Alla definizione dello stile facciamo quindi seguire:

class "GtkWidget" style "default"

Leggi: applica lo stile "default" a quei widget la cui classe è GtkWidget (ossia tutti).

Cosa manca? La definizione dei colori da usare. È vero che ho usato i colori simbolici, ma è pur vero che debbo dare una associazione iniziale tra colore simbolico e colore reale da usare se l'utente non sta usando colori propri. Per cui, prima delle due predecentei definizioni, dovrei inserire qualcosa come:

gtk_color_scheme = "fg_color:#000000\nbg_color:#E2E2E2\nbase_color:#ffffff\ntext_color
:#000000\nselected_bg_color:#3063B1\nselected_fg_color:#ffffff"

Sostituite, nel leggere, a \n il carattere "a capo" e vi sarà semplicissimo riconoscere 6 definizioni di colori.

A questo punto scrivete il tutto nel giusto ordine in un file di testo, salvatelo col nome gtkrc, mettetelo in una cartella dal nome gtk-2.0, mettete la cartella in un'altra cartella dal nome che più vi piace (GlossyDumb), comprimete il tutto come file tar.gz e cambiate l'estensione in gtp: ecco preparato un tema, pietoso in verità, che sfrutta le nuove caratteristiche di GTK+ 2.10 e GNOME 2.18. Giusto per farmi ridere dietro, lo potete scaricare qui.

Diciamo che, scegliendo gli stessi colori, il tema Glossy appare così:

Un approfondimento

A chi mi chiedeva quanto lavoro di porting del codice fosse stato effettuato, rispondo zero! Tutto il lavoro per sfruttare la possibilità di ricolorare i temi è praticamente limitato ai file gtkrc. Mi pare che al momento solo il tema Crux (tra quelli forniti con gnome-theme) non stia usando i sei colori simbolici riconosciuti.

Ad esempio, il citato location widget di Nautilus è solo un widget come gli altri e come tale può essere gestito nei file gtkrc, specificando uno stile e applicandolo a quel tipo di widget:

style "nautilus-location" {
  bg[NORMAL] = mix (0.5, "red", @bg_color)
}
widget "*.nautilus-extra-view-widget" style:highest "nautilus-location"

Non ho idea di cosa possa venire fuori miscelando metà rosso puro ("red" == #FF0000) e metà colore simbolico al momento in uso per lo sfondo, però il punto è che la gestione è demandata alla definizione, non all'applicazione.

Conclusioni

Sarà interessante vedere quanti temi di terze parti faranno uso di questa caratteristica e con quele inerzia. L'uso di nomi e la presenza delle espressioni, se ben applicati, più forzare il creatore di tema a concentrarsi più sui rapporti di proporzione tra i vari elementi ([xy]tickness!!) che sul colore: visto che posso cambiarlo, il colore diventa secondario nel giudizio su un tema, le scelte su come disegnare i singoli widget no.

Allo stesso tempo c'è da considerare che, allo stato attuale, la personalizzazione dei colori è stata pensata e implementata, per l'appunto, come personalizzazione. Non è possibile definire uno schema di colori e distribuire solo lo schema. Ciò potrebbe cambiare in futuro, ma la funzionalità dipenderebbe sempre da quanti temi saranno in grado di gestire la personalizzazione dei colori.

Temizzare o non temizzare, questo è il dilemma

Update: a quanto pare ho premuto Pubblica invece di Salva come bozza. Nel Capitolo 4 c'era solo il primo periodo e anche gli altri avrebbero avuto bisogno di qualche limatina. Per salvare capra e cavoli, aggiorno solo il Capitolo 4.

Visto che questo in parte sta diventando pian piano un blog di rumor, tanto vale prendere la cosa sul serio e parlare delle novità del futuro GNOME per quanto concerne i temi.

Capitolo 1 - In cui Gnomo mette insieme vari pezzi già esistenti per rendere la vita più facile a Utente.

Come preannunciato da Felipe e dai vari autori sui rispettivi blog, nell'attuale versione di sviluppo di GNOME (SVN/trunk) è finalmente disponibile un nuovo metodo per l'installazione dei temi di GNOME.

Il nuovo metodo prevede:

• un nuovo tipo MIME application/x-gnome-theme-package (che è un sotto-tipo di application/x-compressed-tar e che ha come estensione .gtp)
• un nuovo file .desktop per la gestione di questo tipo MIME
• una nuova opzione a riga di comando (-i) per il programma gnome-theme-manager

Grazie a queste aggiunte è possibile creare un file tgz contenente il tema in questione, cambiare l'estensione da tar.gz in gtp e distribuirlo. Una volta che questo file giunge sotto al puntatore fremente dell'utente, è possibile per l'impaziente utente fare doppio-clic sul file: in virtù dell'associazione tipo MIME <-> file .desktop <-> applicazione di gestione, verrà avviato gnome-theme-manager con l'opzione -i di cui sopra e il nome del file come argomento. Il programma gnome-theme-manager provvederà così a scompattare il pacchetto e a copiare i file che compongono il tema nella directory $HOME/.themes o $HOME/.icons (a seconda se è un tema per GTK+, Metacity o per le icone) e a mostrare la simpatica domanda qui sotto ritratta:


È anche possibile trascinare i file sulla finestra di preferenze del tema per installarli, ma ciò era già possibile in passato. La novità sta nella associazione descritta sopra (e nei bugfix a codice malfunzionante).

Una nota: non ho provato né controllato, ma il pacchetto di tema deve contenere un tema e nel formato corretto, altrimenti tutto il lavoro va a meretrici. Contattate quindi il vostro pusher preferito di temi e ditegli che se in futuro un tema non si installa sarà tutta colpa sua. Ah, se il vostro pusher preferito di temi vi fornisce assieme tema per le icone e per i widget, ricordategli che gli spaghetti e la polvere da sparo sono stati entrambi importati dalla Cina, ma nessuno dei due ha avuto grande successo finché a qualcuno non è venuto in mente di SEPARARE I DUE PRODOTTI!!![1]

Capitolo 2 - In cui Gnomo si fa bello per un appuntamento al cinema con Utente.

Come ritratto nella precedente immagine, il motore di temi Clearlooks ha una nuova opzione di stile, GLOSSY.

Niente di rivoluzionario, ma solo una opzione che varia il tipo di gradiente applicato al widget in questione. Come esempio è disponibile il tema Glossy (che non è cmq il tema predefinito), che oltre all'opzione GLOSSY presenta un lieve cambio di colore:

Il bordino blu attorno al menù è presente anche nel Clearlooks semplice (come detto Glossy è solo un'opzione del motore di tema Clearlooks per cambiare il tipo di gradiente). Inoltre è possibile modificare il raggio degli spigoli di alcuni widget, come per esempio i pulsanti ed ottenere, al livello massimo, qualcosa come:


(sì. ci sono degli artefatti visivi, ma ho usato il valore di raggio massimo e lo scopo non credo fosse quello di avere pulsanti "tondi" a la Aqua, ma solo angoli non spigolosi).

Capitolo 3 - In cui Utente si accorge che Gnomo nasconde qualche segreto

Altra novità della serie "sono anni che tutti la aspettavano" è la possibilità di scegliere un tema e cambiare il colore.

L'annoso ritardo può forse essere giustificato dal fatto che ora tutto funziona come dovrebbe: implementare una funzionalità simile in prededenza avrebbe richiesto soluzioni arrangiate. Ora invece tutto lo stack funziona nel modo dovuto.

Per farla breve, GTK+ fornisce la possibilità di definire dei "colori nominali" e la possibilità di definire variazioni di colore, i temi fanno uso di queste caratteristiche e usano dei nomi standardizzati per i colori base e le funzioni offerte da GTK+ per variare colore (esempio, darker(@bg_color) per definire il colore dello sfondo delle linguette delle schede in secondo piano, dove bg_color è il colore nominale usato per lo sfondo), gnome-theme-manager fornisce un'interfaccia per far definire all'utente i valori di quei colori base, valoro che vanno ad applicarsi a tutti i temi che prevedono la personalizzazione del colore.

Certo non si possono fare cose complicate come con la modifica diretta del file del tema (tipo usare il giallo per i menù e rosso per le barre di avanzamento), ma se ad esempio Clearlooks vi sembra troppo blu e volete cangiarlo in verde, allora questa è la nuova feature che fa per voi.


Con due semplici clic ho cambiato i due colori principali del tema Glossy (sfondo della finestra e sfondo dell'elemento selezionato). Tutti i widget si sono adattati alla modifica. A questo punto sarebbe anche possibile cambiare tema dei controlli, usando quindi un diverso motore, mantenendo i colori scelti (a patto, l'ho già detto, che il tema usi i colori nominali).

Capitolo 4 - In cui Luca dichiara apertamente a Utente cosa pensa di Gnome

Non si tratta, è certo, di cambiamenti epocali o caratteristiche che non siano già state viste altrove. Lo stile Glossy per i pulsanti e per i radio e checkbutton, in particolare, altro non è che un port del tema Ubuntulooks. Le possibilità di cambiare colore è presente in altri ambienti da lunghissimo tempo - così come è del tutto assente in altri.

Però, se provo a cambiare punto di vista, smettendo i panni dal piccolo geek che settimanalmente aggiona la sua sandbox della versione di sviluppo, indossando quelli del semplice utente, magari appassionato, che passa in toto da una versione stabile a una successiva, mi accorgo che questi piccoli e insignificanti insiemi di pixel variamente colorati hanno un discreto impatto sul lato psicologico e emozionale/emotivo che riguarda le interfacce utente.

Quando aggiorno un programma, mi aspetto che accada qualcosa di figo. Un semplice "abbiamo corretto 120 bug" lascia nell'utente appassionato un senso di insoddisfazione (oltre a una sorta di pernacchione dentro che ti fa dire: ma allora cosa cacchio ho usato fino ad ora?). Se ci sono solo bug corretti, l'utente appassionato non ha niente da mostrare in giro con cui fare il gradasso. Niente con cui affermare la "superiorità delle propria diversità"

È solo il classico "anche l'occhio vuole la sua parte" condito da un po' di "scopa nuova, spazza bene". Oppure, per chi se la ricorda "Io ce l'ho profumato"[2].

Non a caso, nelle varie recensioni delle varie versioni di Mac OS X scritte da John Siracusa su arstechnica.com c'è quasi sempre una sezione dedicata ai piccoli cambiamenti nei componenti della UI. Come fare altrimenti a dichiarare a piene lettere che si sta usando una nuova versione?

Le piccole modifiche a Clearlooks vanno forse lette in questa prospettiva. Sarà una emerita cazzata, ma se non cambi un po' la tonalità del colore o la curvatura dei bordi dei pulsanti, allora non hai rilasciato veramente una nuova versione.

Certo, magari c'è chi si lascia andare un po' la mano e rivoluziona completamente l'interfaccia utente. La cosa accade, tipicamente, se rilasci il tuo sistema operativo ogni 5 anni. Per giustificare una grande attesa ci vuole un grande cambiamento[3]. E non importa se tagli via cosa come la barra dei menù (qualcuno ha detto Windows Vista?).

Allo stesso tempo il ciclo di rilasci di GNOME è forse troppo rapido (6 mesi): un piccolo cambiamento per ogni versione e ti ritrovi dopo 6 versioni a non avere più piccoli cambiamenti da applicare. Ma a quel punto sono passati 3 anni, lo stile grafico in voga è ormai cambiato e forse è il caso di cambiare tema; esattamente ciò che è successo quando si è scelto Clearlooks come tema predefinito ed esattamente ciò che pare succederà a MacOS con Illuminous.

Un ultimo commento sulla personalizzazione dei colori: a me pare che fornisca tutto quello che serve, un perfetto zen di minimalismo e funzionalità. A questo punto il passo successivo potrebbe essere permettere la definizione e installazione di soli schemi di colore. Non credo infatti che tutti i vari temi Clearlooks-based presenti su http://art.gnome.org presentino cambiamenti diversi dai colori usati rispetto al Clearlooks originale.

PS Felipe, il motore Clearlooks è sempre stato sviluppato attivamente, specie per quanto riguarda la pulizia del codice; semplicemente essendo incluso in gtk-engines non ha ricevuto la stessa enfasi sulle novità di un motore stand-alone.

[1] di Corrado "Vulvia" Guzzanti
[2] "... l'alito. Con Mental"
[3] noto anche come "Principio di Chinghiale-Pennello"

Feed your Browser

Commit riuscito della più innovativa innovazione innovante di GNOME 2.17/2.18. Ecco una traduzione del comunicato ufficiale:

9 gennaio 2006, The Internet - Il Gruppo Permanente Riunito di Controllo e Miglioramento degli Elementi Grafici Iconici [1] è lieto di annunciare la disponibilità del nuovo elemento grafico iconico di Epiphany. Questo nuovo elemento grafico iconico intende continuare la recentissima felice e produttiva tradizione di miglioramento dell'interfaccia utente del miglior programma per l'esplorazione attiva del Web.

Il nuovo elemento grafico iconico si colloca a pieno titolo nello spirito di cambiamento e rinnovamente che permea ogni rilascio di GNOME: tutti gli utenti di Epiphany e di GNOME beneficeranno del nuovo elemento grafico iconico durante le giornaliere sessioni di esplorazione del Web; ancor più beneficio trarranno da questa attesissima novità tutti quegli utenti che hanno necessità di visitare giornalmente nuovi siti conformi a ciò che, con una parola, è definito Web 2.0 e tutti quegli utente che per questioni professionali o lavorative hanno bisogno di individuare in modo rapido e automatica sorgenti di notizie distribuite.

Dal punto di vista sociale, poi il nuovo elemento grafico iconico getta un ponte tra il libertino mondo del software libero e il livoroso mondo del software proprietario, per poi rigettare un secondo ponte tra il flautulento mondo del software proprietario e di nuovo il furbesco mondo del software libero.

Commentando questa notizia, Diego Escalante Urrelo ha dichiarato: «Absolutely sexy» prima di chiudersi in bagno per una buona mezz'ora per l'emozione. Rodnew Dawes ha invece ammesso a malincuore che avrebbe gradito avere il nuovo elemento grafico iconico nel suo modulo gnome-icon-theme, ma non è riuscito per tempo a trovare un nome che ben si adattasse a questa straordinaria novità.

Nota: il reale aspetto del nuovo elemento grafico iconico verrà mantenuto segreto fino al rilascio della versione finale di GNOME, onde evitare ad aziende concorrenti di rubare l'idea.

Come membro del Gruppo Permanente Riunito di Controllo e Miglioramento degli Elementi Grafici Iconici debbo purtroppo con amarezza constatere che, usando una espressione popolare, i buoi sono ormai scappati. Per colpa mia, purtroppo, il segreto sul nuovo elemento grafico iconico è ormai di pubblico dominio, avendone fatto anzitempo il commit sul server SVN di GNOME. Per questo motivo, onde evitare che i soliti siti di rumor diffondano le notizie per primi guadagnando punti e posizioni nella classifica dei siti più visti e per oscurare il di certo meno atteso evento che in queste ore sta interessando gli utenti Apple, mi trovo costretto a mostrare un'anteprima dell'elemento grafico iconico di cui sopra:



1. Io e Andreass Nielsson

Anniversari coincidenti

Ad un anno esatto dall'abilitazione del mio account sul cvs di GNOME, ecco che è stato completato il passaggio a svn.

Coincidenze come queste danno da pensare... C'è forse un disegno divino dietro a tutto ciò, segnali che dovrei interpretare unendo i puntini che il destino mi propone?

Ad ogni modo per il momento:

1. debbo andare a cercare qualche informazione in più sull'uso di SVN (tipo come fare ad aggiungere/rimuovere i file e se c'è necessità di qualche opzioni tipo il -kb di CVS per il commit iniziale di file non di testo)
2. il servizio bonsai è stato dismesso :-( Il che vuol dire che non è possibile sapere quali cambiamenti sono avvenuti sul server SVN nelle ultime X ore. Razzo, era dannatamente comodo sapere in quali moduli erano avvenuti cambiamenti e quali. Ora come faccio a scegliere quali moduli ricompilare con jhbuild????