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????
   

Cercasi pixel disperatamente

Tempi duri per chi, come me, se ne sta ancora aggrappato come un'attinia al suo vecchio, caro monitor CRT.

Anche escludendo i problemi personali -- personali nel senso che il mio monitor CRT da 17 pollici da un po' di tempo sta sfocando due terzi di schermo a partire dal centro, cosa non molto bella alla vista (nel senso dei pochi decimi che ormai sono rimasti) e che genera un bel po' di casini quando disegno icone non HighContrast per GNOME... quasi quasi faccio come Leah Culver... Chi è Leah Culver? Una ragazza che aveva bisogno di comprare un nuovo portatile, anzi per precisione un MacBook, ma che come il sottoscritto non aveva sufficienti dindi: invece di rinunciare, come il sottoscritto ha rinunciato al portatile e rinuncerà per un bel pezzo al monitor, ha organizzato una "raccolta fondi" vendendo spazi pubblicitari sul coperchio del suo futuro portatile. Magari dovrei farmi sponsorizzare la traduzione di GNOME... -- dicevo, escludendo i summenzionati problemi personali, nel prossimo futuro potrebbe essere opportuno fare un pensierio a schermoni dalla risoluzione esagerata per vantarsi con gli amici.

Dopo infatti il rumor sulle icone a 512x512 pixel nel futuro MacOS X Leopard, dopo l'uso di icone a 128x128 pixel in Oxygen, ecco che la moda dell'alta risoluzione sbarca in Tango. Il nostro benamato mastro pittore Jimmac ha recentemente espresso un suo parere sulla questione, ossia che non è affatto contrario all'introduzione nelle linee guida di Tango di una ulteriore opzionale misura: Really Large(TM)

Per provare il tutto, ha appena messo su flickr un po' di prove:

• cartella
• schermo
• cd-rom
  
• web
• logo di Banshee

Da tenere presente che le icone originali sono in SVG, pronte quindi ad essere scalate senza problemi di sorta.

Si tratta per il momento di prove, un interessante esperimento che credo Jakub rimuginasse da un po'. Oddio, personalmente non trovo affatto brutte le icone in stile Tango quando sono scalate a più di 64 pixel: i bordi e le linee che diventano sempre più grandi e sempre più fumettosi all'aumentare della dimensione, mi sono particolarmente simpatici. Anzi, visto che un'icona è una rappresentazione iconica, per l'appunto, di un oggetto reale, meno dettagli ci sono, meglio è (nel senso che più dettagli metto nell'icona di una stampante più l'icona rappresenta una particolare stampante, meno l'icona è rappresentativa per tutte le altre stampanti).

D'altro canto non tutti i dettagli vengono per nuocere, Jakub non è certo un novellino e i display ad alta risoluzione prima o poi saranno una realtà da affrontare... e pensare che il mio monitor fatica a farmi vedere ben benino le icone a 48 pixel :-((

PS felipe, la questione è un po' articolata, spero di completare quanto prima un post sull'argomento.

PPS ovviamente dimenticavo una prova pratica di uso reale delle icone hi-res

Questo post verrà pubblicato in forma ridotta...

... per venire incontro alle vostre limitate capacità mentali¹

Mi domandavo, dopo il recente sciopero dei giornalisti (quello in cui i servizi erano senza nome per protestare contro il fatto che i servizi stessi li realizzano giovani giornalisti poco stipendiati e li firmano vecchi giornalisti poco propensi a lasciare il posto, se non ho capito male) e il nuovo sciopero di oggi (quello in cui i telegiornali vanno in onda in forma ridotta per protestare contro gli editori che vogliono mettere flessibilità in ogni dove):

• è lo stesso sciopero? o sono due scioperi uno dopo l'altro con motivazioni simili a diverse?
  
• si sono accorti i giornalisti che protestavano ieri per i giovani non pagati a lavorare e i vecchi foraggiati in panciolle che la stessa cosa accade anche in: ospedali, università, centri di ricerca, studi di avvocati, studi di notai, enti privati, enti pubblici e financo al parlamento (e sicuramente dimentico qualcosa)?
• si sono accorti i giornalisti che protestano oggi per l'aumento indiscriminato della flessibilità che la stessa cosa accade in %(lista_precedente), fabbriche, officine, call center e tanti, tanti altri posti?

Conclusioni, personali, ma credo un po' universale, per lo meno nell'ambito delle chiacchiere da bar:

• a me, cosa ca##o me ne frega di avere in futuro giornali, notiziari e telegiornali peggiori per colpa dei vecchi in panciolle che rubano in lavoro² ai giovani e degli editori che tengono tutti flessibili se ho già adesso ospedali, scuole, università, centri di ricerca, studi professionali, fabbriche, officine, call center, catene di informatica, catene di elettrodomestici, catene di bricolage e financo il parlamento nelle stesse condizioni?³

1. vecchia battuta di Daniele Luttazzi.
2. nel senso che qui in "datore di lavoro" è il giovane...
3. ovviamente con tutto l'affetto che posso avere nei confronti dei giovani a cui viene rubato il lavoro e nei confronti di lavoratori costretti a lavorare in precariato, prima che mi si accusi di chissà quale nefandezza verbale

And the winner is...

Lo ammetto: usare software dal cvs sarà anche figo, ma ti toglie tutto il gusto del passaggio in blocco da una versione all'altra, con le migliorie tutte assieme, tutte in una volta.

Se poi ci aggiungiamo che il nostro software preferito è rilasciato una volta ogni sei mesi con cambiamenti incrementali invece che ogni 2 o 3 anni con modifiche rivoluzionarie tenute più o meno segrete, allora anche il povero utente medio si unisce al coro gridando: «Ma qui non cambia mai niente!!»

«E invece no», come direbbe Lucarelli in BluNotte. Tutto cambia, in caso contrario appassisce e muore (citazione più o meno volontario da qualche vecchio albo degli X-Men).

Prendiamo ad esempio il file manager Nautilus. La versione di sviluppo parrebbe identica alla versione stabile. Anche il sito appena linkato è fermo ai tempi della versione 2.12. Peccato che in queste ultime 3 settimane (ossia dall'apertura del ramo di sviluppo) ci sono stati i seguenti cambiamenti:

• nuova icona disegnata seguendo lo stile Tango (OK, non è 'sto gran cambiamento, ma fa molto figo, specie rispetto alla vecchia icona)
• uso diretto di Cairo per disegnare i bordi arrotondati nelle etichette delle icone selezionate (che ci crediate o no, fino ad ora l'effetto era realizzato usando un file di immagine PNG con cui creare una maschera)
• rimozione dei metadati di un file (simboli, posizione, ingrandimento dell'icona) quando lo stesso è rimosso esternamente (per esempio con rm)
• "inseguimento" della selezione quando si cambia tipo di ordinamento (attualmente se seleziono un file e poi cambio criterio di ordinamento, il file potrebbe scomparire nella parte non visibile della vista)
• "congelamento" della vista a icone durante il cambio di nome di un file (in pratica non viene aggiornata così da evitare problemi analoghi a quello del punto precedente)
• gestione della scroll well del mouse durante il "rubberbanding" (in italiano: mentre si selezionano file nella vista a icone trascinando il mouse e creando il rettangolo semitrasparente di selezione, è possibile fermare il trascinamento mantenendo premuto il tasto del mouse e continuare la selezione facendo ruotare la rotellina di scorriemento... più facile a farsi che a dirsi....)
• limite a 16 caratteri del pulsante menù di posizione (quello in basso a sinista nelle finestre spaziali)
• nuova infrastruttura di registrazione degli eventi del file manager (niente che serva all'utente, utile invece per gli sviluppatori per capire dove e come eventualmente il programma va in crash)

OK, OK, già sento voci critiche dire che non è chissaché, che manca ancora questo e quello, che Konqueror è meglio, che avrebbero dovuto pensarci prima...

Allora vi aggiungo un po' di pettegolezzi: nessuno di questi cambiamenti è stato direttamente implementato da Alexander "Capitano, mio capitano" Larsson (leader del progetto) il quale ha pubblicamente dichiarato che non si dedicherà a Nautilus perché impegnato nella riscrittura dello GNOME Virtual File System, spostando il tutto in glib ed eliminando i vari problemi di vecchiaia e implementazione; inoltre la metà dei cambiamenti viene dal lavoro di Gene Z. Ragan, ex sviluppatore Eazel che appunto nelle due ultime settimane, dopo aver lasciato Apple e per provare qualcosa di nuovo in Dreamworks[1], ha ripreso a scrivere codice per Nautilus. A un ritmo direi impressionante, specie considerando i cambiamenti avvenuti dopo il fallimento di Eazel al codice di Nautilus. Il tempo di tornare in carreggiata e credo proprio che la versione 2.20 sarà spettacolare.

Un altro aggiornamento che spero sia gradito (visto che sto contribuendo anche io) riguarda Epiphany: nuove icone "temabili" in stile Tango. Cosa vuol dire? Che la vostra barra degli strumenti passa da così:

a così:

e che sarà possibile cambiarle nei temi delle icone, basta usare i giusti nomi.

[1] lo sapete, vero che in Dreamworks usano GNOME?

In ritardo come sempre

Forse sono io che ho capito male, ma dei giovani adolescenti con alle spalle i problemi non tipici dell'età picchiano un coetaneo disabile, "pronunciando frasi denigratorie nei confronti dei down" e la procura inquisisce Google Italia srl per diffamazione? Anzi la finanza (???) ne perquisisce la sede.

Non avrebbero piuttosto dovuto inquisire i ragazzi (ed eventualmente i loro genitori) e perquisire le loro case?

Cioè, se io sono una testa di cazzo e picchio il mio povero cane scattando foto e metto queste foto su flickr, la colpa è di Yahoo! Italia? Magari era nelle condizioni di uso del servizio e non me ne sono accorto, debbo controllare.

Non riesco a capire poi perché dover regolamentare la rete per evitare che tali situazioni si ripetano in futuro. Saranno gli anni passati a dimostrare teoremi matematici, ma ammettiamo che il video non fosse stato reso pubblico su Google Video, nessuno lo avrebbe visto, nessuno si sarebbe indignato (pochi, in verità, se come sembra era tra i più votati nella sezione divertenti), nessuno avrebbe indagato. La conclusione è ovvia. Meno male che c'era google video e che gli adolescenti non erano poi così furbi come pensavano.

Dunque, questa storia ci ha insegnato che:

1. se picchi qualcuno e ne fai riprese, non metterle su Internet, per lo meno non dove siano accessibili a tutti
   
2. se picchi qualcuno e ti riprendono, spera che le immagini non finiscano su Internet
3. se sei il garante della privacy, fatti i privacy tuoi che a interpretare i risultati di una ricerca ci penso da me
4. se sei la procura della repubblica (ma anche il legislatore) forse il gerovital non è più sufficiente e si dovrebbero rinnovare e ringiovanire le risorse umane

Per altri commenti sulla storia, leggete qui.