Speak Up!

C'è una cosa che, finché non si prova per esperienza diretta, non si riesce forse ad apprezzare: l'accessibilità del software (e dei formati, certamente) non serve solo a una minoranza.

Prendete il sottoscritto, per esempio. OK, mi mancano 5 diottrie per occhio, ma una volta inforcati gli occhiali riesco comunque a vedere e riconoscere il mondo che mi circonda. Eppure negli scorsi giorni ho usato lo screen reader Orca. Non solo: sono stato ben felice che lo screen reader Orca esistesse, funzionasse e fosse installato e (sufficientemente) facile da attivare in Ubuntu.

I dettagli? Eccoli.

L'esigenza che avevo era confrontare un documento cartaceo con un documento elettronico (nello specifico un documento di Word di una cinquantina di pagine) e verificare che il secondo corrispondesse al primo (comprese virgole, apostrofi e virgolette). Avrei potuto passare il tempo a girare la testa e lo sguardo dall'uno all'altro, a muovere le mani dalla tastiera ai fogli di carta, alternandomi tra la pressione di tasti e il voltare pagine, oppure avrei potuto invocare la mia (limitata) arguzia e la potenzialità del software libero e lasciare che il computer facesse quello per cui dovrebbe essere progettato: rendermi la vita più facile.

Così ho attaccato le cuffie, ho fatto partire Orca, ho modificato lievemente la configurazione predefinita in modo che leggesse non solo le parole, ma anche la punteggiatura¹, ho aperto il documento e ho lasciato che una voce sintetizzata leggesse al posto mio il documento elettronico, riga per riga, mentre il mio sguardo era fisso sul cartaceo. Per il 97% del tempo ho solo dovuto premere freccia giù per passare alla riga successiva, guardando lo schermo solo nel caso di correzioni².

Sono stato una minoranza, forse quasi una singolarità, ho avuto una esigenza che il software open source  (Orca, espeak, GNOME e Ubuntu) è riuscito a risolvere in modo facile e immediato. Sarà banale, ma sono contento, non per me, ma per tutte le minoranze.

[1] a onor del vero ho anche aumentato la velocità di lettura, ma questo solo per sbrigarmi...

[2] avrei anche potuto farle, mi si passi la battuta infelice, "ad occhi chiusi", visto che spostandosi all'interno della singola riga era possibile individuare il punto di intervento grazie soltanto a quello che ascoltavo

For your pleasure

Uploadare è una noia infinita... anche se richiete un tempo finito, è sempre comunque dannatamente tanto.

Beati voi che dovete solo scaricare, nello specifico potreste:

• visualizzare la versione finale della presentazione per il seminario Cultura Senza Barriere sul Slideshare.net a questo indirizzo (richiede flash, se non ricordo male)
  
• visualizzare la versione senza immagini dello stesso, sempre su Slideshare.net, ma presso diverso indirizzo
• scaricare direttamente il file ODP (non richiede flash, ma sono circa 20 MB)
  
• scaricare anche un file "accessorio" che in qualche modo documenta come eseguire la parte pratica del seminario (questo secondo file in futuro potrà ricevere qualche aggiornamento, tra cui togliere la parola "froceria" - e se uso questo termine la colpa è tutta di The Salty Dog - e aggiungere la parte su Orca - per la quale saremmo andati un po' a braccio)

Per impostazioni predefinite dell'utenza di Cultura Senza Barriere su slideshare sembra usare la condizione "No Derivative Works" delle licenze CC. Quando domani mattina la mia affezionatissima Flavia si sveglierà e lo confermerà, direi che le nostre slide possono essere dichiarate e usate come by-nc-sa. Se mai dovrete fare un talk su Ubuntu (o GNOME) e l'accessibilità...

Nel prossimo episodio...

Un'ora. Meno un po' di minuti. Meno un curioso inconveniente legato all'ingranditore di Orca e alla clonazione dello schermo¹. Meno il fatto che io e Flavia andiamo sì in piena sintonia, ma di getto e d'istinto e non perché si siano mai fatte prove col cronometro.

Risultato: se eravate² in quel di Padova, facoltà di Psicologia, piano secondo, aula B non avete avuto modo di gustare tutto, ma proprio tutto quello che avevamo in mente di dire. Gran parte, che speriamo abbiamo esposto in modo chiaro e adeguatamente approfondito.

Conseguenza: mi sa che oltre a rendere disponibili le slide per chi volesse vederle (peraltro già su slideshare, anche se in versione full-a11y senza immagini), oltre a rendere disponibili i nostri appunti su cosa e come fare la parte pratica per chi volesse riutilizzarle per un altro evento (giusto il tempo di togliere qualche colorita annotazione personale), oltre a continuare la collaborazione con le magnifiche persone di CSB (un grazie grande grande a Marco e Federica, un a presto a tutte le persone che abbiamo conosciuto), mi sa che nelle capoccette dei vostri affezionatissimi si sta facendo strada l'idea di preparare un po' di video.

Non di promozione. Non di divulgazione. Quanto piuttosto di chiarimento. Il nostro seminario voleva essere pratico. No chiacchiere, botte (cit.). Se l'accessibilità è importante, non basta dire "noi ce l'abbiamo", dobbiamo aggiungere "e funziona così"

Ovviamente io alla regia e Flavietta alla voce sexy narrante :P

[1] sì, il sottoscritto e Treglia Alessio stanno già provando a renderlo riproducibile e segnalarlo come bug.
[2] lo scrivo in piccolo, ma il grazie che inviamo a Claudio Arseni per essere passato è enorme

Dolcetto o scherzetto? - the end

Va bene, la pianto. È solo che la cosa è imbarazzante. Cioè, un conto è andare a un megaraduno di nerd e geek come il LinuxDay, un conto è se ti invitano ad andare a un seminario sponsorizzato dall'Università di Padova.

È una cosa seria, bisogna sapere quello che si dice... mica ci può mandare una Weisghizzi tutta da sola, no? :P

La domanda che al momento frulla nella mia testa piuttosto è: riuscirà il simpatico duo Deindre & elle.uca¹, supportati dalla prorompente fama di Ubuntu, a tenere il passo con gli altri seminari? Ma sopratutto, secondo voi, dovremmo fare un video di anteprima?????

Ah, sì, prima che me ne dimentichi. La storia del sono il migliore in quello che faccio² diciamo pure che è vera, ma qualche limite questo vecchio canadese ce l'ha pure lui. Per cui, se stavate pensando a portare avanti una spedizione contro Galactus, chiedete ai FF

[1] He's a scarfaced Catholic grifter trapped in a world he never made. She's an enchanted junkie magician's assistant from a secret island of warrior women. They fight crime!³
[2] anche se a volte quello che faccio non è piacevole... SNIKT!
[3] ma come fa Alexander "Capitano, o mio capitano" Larsson a mettere in ogni email una firma del genere, ogni volta diversa????

Donkey Kong (aka scaricabarile)

Gli amici si vedono nel momento del bisogno e questo, lo so, è uso privato e criminoso del mezzo pubblico. Criminoso!

Mi si dice (ministero dell'interno, pubblicazione numero 4), di ammettere al voto assistito anche gli handicappati di natura psichica allorquando la relativa condizione patologica comporti una menomazione fisica che incida sulla capacità di esercitare materialmente il diritto di voto.

D'altro canto, per quanto ne sapevo io, le linee guida o le interpretazioni erano sempre state più o meno queste, riassunte in

Cfr. Cons. di Stato, V, 31 gennaio 2007, n. 387: “è da escludere … che un impedimento che si manifesti esclusivamente o prevalentemente in uno stato di alterazione psichica possa rendere legittimo il ricorso al voto assistito”.

Ora, io sono capzioso e criminoso, ma visto che non sono un medico legale della ASL, né un medico militare, francamente non ho la più pallida idea di quali handicap di natura psichica possano prevedere menomazioni fisiche. Per lo meno non sono sicuro di saper distinguere la sottile linea di demarcazione che intercorre tra handicap psichico che rende l'elettore incapace di intendere e volere e handicap psichico che mantiene l'elettore capace intellettivamente, ma incapace fisicamente. Di certo non credo che il semplice chiedere al menomato se sa il suo nome o cognome chiarisca gran che.

C'è un medico in sala?

Conflitto d'interessi

Alla fine ci sono cascato anche io, dopo tutti gli anni e gli slogan a dare contro al povero Silvio, a pensare che fosse scorretto fare cose come approvare una legge sull'introduzione del digitale terrestre e contemporaneamente essere azionista importante¹ della società che produceva i decoder e proprietario di reti televisive che avrebbero beneficiato economicamente².

Alla fine ho ceduto al lato oscuro, anche se lo so che non ce la farò a concorrere per il premio di 1000$, quando Willie Walker (è una persona, non un fumetto, anzi è uno sviluppatore Sun coordinatore di Orca e di altre cose dell'a11y di GNOME) mi ha detto che stavano pensando ad altre forme di premio anche per chi non avesse completato la quantità sufficiente di lavoro per il premio monetario, ho ceduto, e ho partecipato barando.

Barando sì, lo ammetto, o per lo meno in modo scorrettissimo. Perché va bene che non lavoro per Sun, Novell, Canonical, la GNOME Foundation, la Mozilla Foundation o Google, però in fin dei conti sono pur sempre il maintainer delle icone HighContrast e partecipare al concorso nel doppio ruolo di disegnatore e giudice della bontà delle icone è fare esattamente come il Silvio di cui sopra.

Beh, esattamente... Senza giornali che ti attaccano, giornali che ti difendono anche quando sei indifendibile, ma soprattutto senza il ritorno economico di una pay per view.

Anche perché, rammentiamolo, sono icone per gente con problemi alla vista, se gli mettiamo anche le icone pay per view...

PS sì, lo so, l'accessibilità è una cosa noisissima: icone in bianco e nero talmente grossolane che per dire che sono cariiiiiiine bisogna essere veramente storti, righe e righe di codice che non rendono l'applicazione né più bella, né più rapida, né più funzionale, se non per la solita minoranza rompiscatole che se fossimo tutti maggiornaza, alti, belli, forti, e con 10/10 di vista sai quanto sarebbe meglio il mondo; ma che volete farci, adoro quei lavori sporchi che qualcuno deve pur fare.... mmmmmmmmm... oh sì, li adoro

[1] e non fate i capziosi dicendo "eh, ma mica lui, il fratello Paolo" oppure "eh, ma mica lui, la figlia Marina, neosposa, e il figlio Pierpiero³"
[2] cioè, scemo io che in fondo lo so che il 52% della popolazione mondiale pensa che quello di Silvio sia un comportamento giusto perché l'importante è fare soldi e avere una posizione di spicco e la benedizione di un Dio che benevuole, il 34% dice che è un comportamento scorretto solo perché non si trova nella condizione di poterlo applicare lui, il 12% non sa/non dice, l'1% si attacca e se anche pensa qualcosa è talmente minoranza che non vale la pena di starlo ad ascoltare
[3] oddiooooooo!! Pierpiero!!!! che mi ero dimenticato. Mi ringrazio per avermelo fatto ricordare e mi rallegro da solo

V for Vendetta

Mi segnalano¹ un fastidioso problema nell'accoppiata Orca-Espeak che prontamente faccio rimbalzare qui per dare un po' di visibilità alla questione.

Per chi non sapesse di cosa stiamo parlando, ma anche per chi lo sapesse, Orca è lo strumento di tecnologie assistive di GNOME (o meglio, di tutto ciò che usa AT-SPI, tanto che mi pare di ricordare il commento di qualche KDE-guy del tipo "ma chi se ne frega per ora di fare una cosa del genere in KDE, usate Orca"), ossia quel programma che serve per attivare e gestire sintesi vocale, braille, ingrandimento e altro. Espeak è uno dei motori di sintesi vocale usato da Orca, predefinito in alcune distribuzioni.

Ora, sintetizzando, il problema è il seguente: Espeak legge la "V" e la "X" in modo errato, non come lettere dell'alfabeto, ma come numeri romani.

Per cui, se provate a dare il seguente comando

espeak -v it "1 2 3 4 v"

otterrete la seguente lettura

uno due tre quattro cinque

Il buon Franco Carinato, che mi ha segnalato il curioso comportamento chiedendo se la cosa dipendesse dalla traduzione di Orca, ha anche individuato e risolto il problema, il tutto riportato in una utile pagina sul suo sito. Forse, e dico forse perché non ho provato a farlo e non posso dirvi la procedura, sarebbe possibile risolvere (o per lo meno bypassare senza dover scaricare il pacchetto sorgente di Espeak) la cosa anche direttamente in Orca, che ha anch'esso dei dizionari personalizzabili. Appena provo aggiorno questo post con le istruzioni.

Oppure cambiate accoppiata e usate come Festival come motore di sintesi vocale (che ha anche una strasexy voce femminile).

Inoltre Franco mi ha detto, e ci conto, che la traduzione di Orca verrà passata al setaccio da parte di Nunziante Esposito dell'unione italiana ciechi. Io nel frattempo, per non fare la figura dell'impreparato, mi leggo le varie interviste e interventi di Nunziante rintracciabili via goooooogle...

Tanto per concludere la serie di notizie legate all'accessibilità, un sorridente collegamento che fa ben sperare per il futuro. Che poi, se bastano così poche righe di codice a dare un supporto, di certo parziale, ma comunque presente, mi viene da dire "All Hail WebKit!"

[1] in realtà avrei dovuto scrivere "mi hanno segnalato già parecchio tempo fa, ma sono un accidioso fino all'osso e non faccio mai oggi quello che posso fare tra 4 giorni"

Fratelli coltelli

Premessa: OK, ci sono cascato. Il pesce d'aprile consisteva nel fatto che non si trattava di un pesce d'aprile...

Lo so, pensavate che Marvel Civil War vi avesse messo davanti la scelta più difficile della vostra vita. Capitan America o Iron Man¹? Mister Fantastic o la Donna Invisibile²? L'Uomo Ragno con il tradizionale costume rosso e blu o con quello ipertecnologico rosso e oro³?

No, purtroppo l'era delle scelte non è affatto finita. Ora ve ne attende un'altra: per GNOME/GTK+ è meglio Gecko o WebKit [o entrambi]?

Ma peeeercheeeeé?

"Che ce ne cale?", direte voi "Facciamo un bel livello d'astrazione (magari anche switchabile a runtine) e chi se importa di quello che c'è sotto".

PEEEEEEEB - risposta sbagliata.

Parole di Alp Tocker, non mie, scritte qualche tempo fa (a commento del bug per Yelp per tenere traccia del porting su WebKit), ma pare che a seguire tale strada si avranno solo due grossi problemi:

1. gli attuali livelli di astrazione disponibili (in yelp, devhelp, epiphany e altrove) tra applicazione ed engine sono troppo grezzi per diventare un'API supportata sul lungo periodo, magari da inserire addirittura nelle GTK+;
   
2. se anche se ne scrivesse uno nuovo ed elegante, dovrà per forza seguire la politica del minimo comune denominatore, implementando solo quelle funzioni comuni tra di vari engine (risultando quindi decentemente monco).
   

La soluzione da lui proprosta è quindi supportare per la propria applicazione un solo engine per volta (a run time, o meglio a configure time, oppure tout court) come dipendenza aggiuntiva e parallela. Anche la strada scelta dalle QT 4.4 di incorporare WebKit non è percorribile, data la scarsità di risorse umane delle GTK+ e la quasi necessità di creare un quasi-fork per evitare dipendenze circolari (sempre parola di Alp Toker).

E con ciò cominciano, direbbero a Roma, i cazzi amari. Già perché sarebbe assurdo dire "nelle vostre applicazioni, se avete bisogno di una vista HTML, usate WebKit o Gecko o Gtkhtml, indifferentemente"; GNOME è un ambiente desktop, ma anche una piattaforma e non potremmo certo attrarre sviluppatori di terze parti con qualcosa di così sospeso nel giudizio.

Sarebbe opportuno dire, piuttosto, "il motore di rendering HTML scelto come dipendenza esterna ufficiale per GNOME è XXXXX, se poi ne volete usate un'altro fate pure, però abbiamo valutato e ponderato e XXXXX è cosa buona che fareste meglio a usare anche voi". Su che criterio, però, basare la scelta?

Lucertolone affamato

Di Gecko non si può che dirne bene. In fin dei conti è il nostro paladino che si insinua nel territorio dell'infedele e ne fa strage mozzando le teste e facendone zampillare il putrido sangue (OK, non so bene il perché di quest'immagine cruenta e fideistica, forse ultimamente ho giocato un po' troppo a Faith Fighter). Funziona, funziona bene, nell'ultimo rilascio funziona anche meglio, ha alle spalle uno sviluppo libero quasi decennale e una base utenti che dovrebbe essere il 20~25% dei naviganti mondiali (in perenne crescita?).

Con tutta questa "genuità e garanzia der consumatore" viene da chiedersi che si pone a fare il dubbio di cui sopra. Teniamoci Gecko, punto.

Beh, a essere proprio sinceri sinceri i suoi difettucci Gecko li ha, specie se lo si osserva non dal punto di vista dell'applicazione che quel 20~25% di cui sopra usa tutti i giorni, ma della libreria per sviluppare o abbellire le proprie applicazioni.

Il problema di fondo infatti non è tanto individuare un "well behaving" web browser da usare in GNOME, ma una libreria per permettere agli sviluppatori di applicazioni GTK+/GNOME di inserire contenuti di tipo HTML in modo facile e indolore, così come agli utenti di visualizzare e possibilmente editare tali contenuti in modo standardizzato, completo, stabile, sicuro, affidabile e rapido.

Da questo punto di vista le cose non sono così rosee: Gecko/Firefox infatti usa alcune tecnologie di GNOME e GTK+ per il suo porting in ambienti *NIX, ma in cambio non offre strumenti (leggi API e/o integrazione) adeguati. Un paio di commenti non miei:

Gecko e il lavoro sulle funzionalità di Gecko sono guidati per la maggior parte dal browser Firefox[...] e l'API per l'embedding di Gecko è rimasta non mantenuta e stagnante da lungo tempo; parola di Christian Persch (Epiphany developer).

Usando Gecko ho sempre avuto la sensazione di estrarre chirurgicamente pezzi di un'altra applicazione, invece di usare una libreria ben progettata; parola di Shaun McCance (Yelp developer).

Personalmente ho sempre avuto anche io la cattiva sensazione che la Mozilla Foundation sia troppo (o solo) interessata alle proprie applicazioni, come se Gecko nasca e muoia all'interno dei loro progetti e tutti gli altri (nel senso quelli che debbono scrivere un'applicazione che usi Gecko) farebbero meglio a usare XUL. Andatevi a leggere i changelog di Epiphany e controllate quante volte è si è dovuto rincorrere i cambiamenti di API, anche relativi alla stessa versione di Gecko. Oppure pensate al fatto che, non dico su Windows dove forse è normale, ma nelle varie distribuzioni GNU/Linux ogni applicazione che viene dalla Mozilla Foundation compila e installa la sua versione privata e forse linkata staticamente di libgecko, libnss, libnspr e via dicendo.

Bussola che strizza l'occhiolino

WebKit. O meglio WebKitGtk. Sembra la risposta a tutto quanto manca sopra. Una API che ricalca quella di GTK+/Glib/GObject, uso di tecnologie "native" come Cairo, Pango, Libsoup, GStreamer (e a breve gnome-keyring) ovunque sia possibile, una serie di obiettivi ampiamente condivisibili e la fresca ventata di freschezza che una novità porta sempre con sé. Senza dimenticare che, in quanto fork di KHTML ha anch'esso uno sviluppo quasi decennale.

Insomma, il fatto di essere pensato e sviluppato per essere solo un engine, senza che lo sviluppo sia trainato da un ingombrante browser di riferimento, lo rende ottimo candidato per tutte quelle applicazioni che necessitano di mostrare dei contenuti tipo HTML; inoltre la promessa di avere nell'immediato futuro dei cicli di rilascio semestrali con una stabilità delle API lo rende certo attraente per quelle applicazioni che non hanno risorse umane sufficienti a correggere i propri bug, implementare nuove funzioni e controllare se le API di Gecko sono cambiate senza che nessuno lo annunciasse.

Ora, bene inteso, non sto dicendo che è perfetto, anzi. Innanzitutto è un progetto giovane e probabilmente immaturo (almeno nella sua incarnazione per GTK+ e in confronto a Gecko), in secondo luogo è un progetto giovane e probabilmente immaturo (no, non mi sono incantato), in terzo luogo manca di un adeguato supporto all'accessibilità (sempre nella sua incarnazione per GTK+ e specie per tutte quelle cose tipo ARIA su cui Gecko ha lavorato nelle sua ultima incarnazione in stretto contatto con gli sviluppatori di Orca), in quarto luogo tutta la gestione del https:// e simili deve essere gestita dal browser (ma è una pecca? WebKit in fondo è solo un engine per html...), in quinto luogo non mi è ancora chiaro come e se funzionano i plugin tipo java o flash, in sesto, settimo e ottavo luogo, è un progetto giovane e ancora immaturo (tutti in coro: sono un vinile che si sta incantando, sono un buddista che ti sta gonghiando, sono una crema allora sto impazzendo, sono un bambino e faccio giro giro tondo, giro giro tondo...).

Faith Fighter

Se volete, ribaltando l'ottica, negli ultimi dieci anni lo sviluppo di "cose" relative al web ha visto come unico target mozilla/firefox/gecko: "Abbiamo mozilla, mozilla ci fornisce il web, ce lo fornisce libero, ce lo fornisce rispettoso degli standard, non ci serve null'altro".

Beh, non è più così. Non solo ora abbiamo WebKit, abbiamo anche una serie di sviluppatori che stanno manifestando esigenze che Mozilla non è (stato) in grado e non si è mai sforzato di risolvere: gli sviluppatori di Yelp e Devhelp hanno bisogno di una semplice vista html da inizializzare e gestire in 100 righe di codice, gli sviluppatori di Pidgin e di Empathy vorrebbero aggiungere un po' di vivacità nelle finestre di chat con un numero di righe di codice poco superiore, gli sviluppatori di Evolution potrebbero smetterla di sviluppare e mantenere Gtkhtml, gli sviluppatori di Epiphany desiderano concentrarsi sullo sviluppo della loro applicazione e delle funzioni che vogliono rendere disponibili.

Insomma, stiamo nel bel mezzo di una fase di crisi d'identità e visti i primi commenti direi che non appena WebKit verrà proposto come dipendenza esterna potrebbe scatenarsi una decente guerra di religione.

Io voglio bene a mozilla/gecko, è grazie a lui se in questi ultimi dieci anni ho potuto godermi tutto il porno che c'è sul web e so che attualmente epiphany-webkit non regge il confronto con epiphany-gecko.

D'altro canto, sin dalle prime apparizioni di Galeon/Epiphany, non sono mai stato tanto attaccato a Firefox (come applicazione a sé) forse perché, in quanto "sostenitore" di GNOME (utente e 1/8 di sviluppatore), ciò che voglio è un browser che sì funzioni, ma che sia anche ben integrato nell'ambiente, non solo rispettando delle varie linee guida per l'interfaccia, ma anche usando al meglio le tecnologie della piattaforma di sviluppo di GNOME e fornendone di sue con la medesima filosofia (primo esempio pratico: grazie a GConf e al lockdown fare un chiosco con Epiphany è semplice come impostare 3 o 4 chiavi a true, Firefox richiede, se non erro, un plugin esterno; secondo esempio pratico: a che mi serve scrivere codice per un password manager nel browser se ho già gnome-keyring e seahorse?).

Ora, da un lato abbiamo Gecko che funziona ottimamente, ma che è difficile da integrare, dall'altro WebKitGtk che è stato pensato proprio per essere integrato con facilità, ma che manca della necessaria maturità.

Il piatto è traballante, la scelta degli sviluppatori di Epiphany di usare solo WebKitGtk per la prossima release è coraggiosa (specie considerando che avviene in concomitanza la migliorata integrazione di Firefox in GNOME e tutto il lavoro sull'accessibilità svolto assieme al team di Orca), ma al tempo stesso è la scelta migliore che al momento potevano fare, per il loro progetto e forse per l'intero desktop. Una volta infatti approvato WebKit come dipendenza esterna ufficiale, ogni applicazione di e per GNOME potrà liberamente usarlo per i propri scopi e necessità e a quel punto, se effettivamente valido come sembra, potrà migliorarsi, "imporsi" e darci tante, tante soddisfazioni. In caso contrario, forse altre sei mesi di indefesso sviluppo potrebbero bastare. Chissà se basteranno anche a GtkMozEmbed per sparire del tutto o per essere adeguatamente aggiornato...

Colpo di coda

Visto che questo post è finito col tramutarsi in un j'accuse contro il metodo di sviluppo della Mozilla Foundation, aggiungiamo un altro tassello. Trattasi nello specifico di NSS ossia in Network Security Service.

Per la piattaforma GNU/Linux esistono diversi pacchetti che forniscono dei servizi crittografici, tra cui NSS, OpenSSL, Cyrus SASL, GnuPG, GnuTLS, OpenSSH e altri (kernel incluso). Tutti noi sappiamo che la varietà è cosa buona e bella, ma anche che, se la verità e nel diario, la varietà e nel divario.

Qual è il problema di tale divario? Ovviamente che a seconda di quali e quanti servizi crittografici le mie applicazioni hanno scelto, sarò costretto a ripetere N volte azioni come l'importazione di un certificato.

Non solo, pare che esista una cosa chiamata FIPS 140, una delle solite convalide da fare passare al proprio software per essere usato dal governo americano. Ovviamente tale FIPS 140 è diventata pietra di paragone e misura della qualità di un servizio crittografico. Altrettanto ovviamente è qualcosa che di tanto in tanto va rinnovata e che molto probabilmente richiede un esborso monetario.

Attualmente solo NSS è in una buona posizione con tale FIPS 140: OpenSSL ha avuto dei problemi di "rinnovo", GnuTLS non è mai stato convalidato.

Per ulteriori approfondimenti sulla questione, e sul perché potrebbe essere utile avere un solo servizio crittografico come altri sistemi (al solito Win e MacOS), consultate questa pagina.

Dov'è il problema? È che, al solito, compilare NSS come libreria esterna a Firefox è impresa destinata a fallire. Esiste un pacchetto con i sorgenti (rilasciati sotto licenza MPL, GPL e LGPL) ma in esso non vi è traccia di una infrastruttura per configurare, compilare e installare la libreria. Volete usare NSS? Bene, impazzite pure a ricreare tutta l'infrastruttura includendo il codice nella vostra applicazione e linkando staticamente, oppure compilatevi Firefox (2.0 però, la 3.0 non installa nulla che abbia a che vedere con lo sviluppo). E poi non venitemi a dire che la Mozilla Foundatio è amichevole con gli sviluppatori...

[1] mah, a me sono sempre stati un po' antipatici entrambi
[2] ma volete pagorarlo all'urlare "Fiamma!" e volare coperti da lingue di fuoco?
[3] IMHO ora e sempre costume nero, no, non quella schifezza che c'è nel film, ma questo.... anche se... quello del povero Ben Reilly....

Jens Granseuer è uno stronzo e vorrei che venisse scritto in cielo

Mi girano, sto litigando praticamente con chiunque in questi giorni, per cui potrei essere io a prendermela per cose su cui magari ho torto (Legge di Murphy, ti prego, fa' che non lavori con Emmanuele Bassi e che non gli riporti e traduca il titolo di questo post; se poi una volta tanto riesci a guardare dall'altra parte, fa' che Emmanuele sia in accordo con me...).

Lasciamo però che siano le prove a parlare (vai, Gil Grissom dei poveri). Dunque, questo qui sotto è l'attuale (nel senso di versione unstable, non nella 2.20) nuovo strumento di preferenze per il mouse:

Come potete notare è stata modificato un po' per poter inglobare la scheda Accessibilità, raggruppando tutti i precedenti controlli nella scheda Generale. La cosa non è affatto male: prima per configurare il comportamento base del mouse bisognava spostarsi tra tre schede diverse, ma ci sono alcuni aspetti che, secondo il mio modestissimo parere, importante quanto quello di un foruncolo sul culo dell'umanità, non sono proprio ben pensate:

• il dialogo è alto come il Pirellone
• nella scheda Generali ci sono 5 gruppi
• di questi 5, 3 (tre) hanno una sola opzione (il che, tautologicamente parlando, manda a farsi fottere il concetto stesso di gruppo, no?)
• amichevolmente parlando, forse anche chi ha bisogno di impostare il clic accessibile vorrebbe provare da qualche parte se i modi e i tempi sono adatti per lui

Cosa ha fatto quindi il vostro affezionatissimo? Ha preso il suo bel progettatore di interfacce Glade, ha spostato un po' qua e un po' là i controlli, ha messo un po' mano al codice e ha tirato fuori e proposto questa versione:

Certo, non è una versione perfetta (ci sono degli errori che andrebbero corretti e l'icona di test dovrebbe far provare anche il clic secondario e il trascinamento), ma a mio avviso:

• l'altezza e la larghezza sono un po' più proporzionate
• nella scheda Generali ci sono solo tre gruppi
• i tre gruppi sono raggruppati con una certa logica: dispositivo (a destra o sinistra?), puntatore (velocità e posizione) e per finire interazione (clic e trascinamento)
• l'area di test è disponibile anche per chi sta impostando le opzioni per l'accessibilità

È meglio? È peggio? In assoluto non lo so, a me pare che per lo meno abbia delle potenzialità. E, giuro, il fatto di mettere l'area di test fuori dal notebook mi sembrava una grande pensate, una di quelle cose talmente banali che tutti avrebbero dovuto chiedersi: «Ma come ho fatto a non pensarci io? Dannazione, questo Luca è proprio un genietto...»

Cosa ha fatto il buon Jens? Ha decretato che a lui non piace nessuno dei cambiamenti apportati: il fatto di avere troppi gruppi non è un problema, quelli proposti non hanno logica aggregativa, il test del clic serve solo nella scheda Generali. Conclusione: patch rifiutata.

Sarò io che sto prendendo male alcune cose ("io non ho altro da dire e se tu ce l'hai a me non interessa")...

Feature or Bug?

Nelle note di rilascio, che non mi annoio a linkare qui, non è riportata una nuova caratteristica che, probabilemente, grandi discussioni causerà in futuro. Non è riportato neanche il nuovo tema, ma secondo me solo perché sono tutti indiviosi di Cimi... Tant'è che Fedora 8 avrà come tema una versione di Murrine modificata: Nodoka.. Bah!

Comunque, tornando a bomba: in Eye of GNOME la rotella non effettua più lo zoom. Ohhh! Ahhh! Ehhh! Ma daiiiii!

IMHO: era ora!!

La rotella del mouse nasce come "scrollweel" quindi, tautologicamente, serve a far scorrere qualcosa. Fa scorrere le pagine web quando le si visualizza in Epiphany, fa scorrere i documenti PDF/PS/DejaVu/Comicbook in Evince, fa scorrere i testi in gedit, Evolution e in tutte le caselle di testo, fa scorrere gli elenchi, fa scorrere le viste a icona. Anche il buon GIMP usa la sceollweel per scorrere.

Perché diamine EoG dovrebbe usarla per lo zoom? Perché finora non rispettava le HIG, che dicono, espressamente, che lo zoom deve essere effettuato con Ctrl+scrollweel, anzi aumento del livello di ingrandimento con rotazione della scrollweel verso l'alto, riduzione con rotazione verso il basso.

Se trovate qualche applicazione che non si comporta così, non esitate a segnalarlo su bugzilla. Io ho trovato F-Spot, che si comporta come il vecchio EoG, ma ho un dubbio: segnalo il bug o chiedo che venga realizzata da zero una nuova applicazione in linguaggio C, magari basata su tracker e gegl, con una logica un po' meno perversa? Ho già il nome pronto, o quasi: se la Apple ha le iApps, GNOME potrebbe avere le AppsBox: RhythmBox, PhotoBox, ClipBox e via dicendo

Grafica d'autore

A rilento, ma il progetto (per ora personale) di creare un tema di icone in SVG aderente alla specifica Icon Naming che sostituisca l'attuale HighContrast va avanti.

Ecco qui un po' di nuove icone che sto per committare sul CVS. Ovviamente ogni suggerimento è come al solito benvenuto.

Le motivazioni di alcuni cambiamenti le trovere nel ChangeLog di gnome-themes.

Monocromo

OK, OK, l'immagine non rende giustizia... Ecco allora la spiegazione. Ciò che vedete nell'immagine qui sopra altro non è che l'anteprima di alcune icone per GNOME a contrasto elevato fatte da me in SVG negli ultimi tempi.

Il mio lavoro si è innestato su quello di Jakub "jimmac" Steiner e recentemente è stato inserito nel modulo gnome-themes sul cvs di GNOME :-)

Il lavoro non è finito. Mancano ancora parecchie icone prima di poter fornire tutte quelle richeste dalla specifica Standard Icon Naming di freedesktop.org Se vi andasse di aiutare tenete a mente che linee guida per queste icone si riducono a:

1. semplificare, semplificare, semplificare (usando se possibile le metafore proposte dal progetto Tango)
2. usare una tela di 48x48 pixel
   
3. usare solo bianco e nero con piena opacità (#000000FF e #FFFFFFFF nella notazione di Inkscape)
4. disegnare sempre un bordo attorno a tutta l'icona di colore "inverso"
5. disegnare bordi, linee e dettagli larghi almeno 4 pixel (come da richiesta dell'HIG)
6. posizionare nodi e bordi delle forme sulla griglia (evita antialiansing inutile)
   

A parte comunque le icone mancanti, è necessario anche il "porting" di parecchie delle icone fatte da Jimmac, dove per porting intendo l'applicazione di piccole modifiche a icone esistenti in modo da essere aderenti ai punti 1, 5 e 6 (jimmac ha disegnato infatti alcune icone tempo fa, usando però una tela di 48 punti, bordi di 3~3,5 pixel e senza il posizionamento dei nodi; tali icone non sono brutte, anzi, solo che si notano degli inutili artefatti, come indicato ai commenti 8 e 9 del bug numero 319041).

Parliamo di accessibilità - chiacchierata 3

A questo punto direi si possano tirare le somme. Beh, per la verità è un atto dovuto, visto che le scelte qui descritte le andrò ad inserire in alcune traduzioni di GNOME, ivi compreso lo gnome-control-center.

Ora, quelle che sono fornite sono delle funzioni. Quindi la traduzione deve avere senso se nella forma “funzione di xxxx dei tasti”, dove xxxx è un sostantivo. L'esempio più ragionevole è la traduzione di repeat keys: funzione di ripetizione dei tasti. Semplice, chiaro, va giù nelle orecchie come un buon wisky di malto nelle budella. Insomma, direi che è una buona traduzione. Insomma, credo fermamente che una traduzione tipo sostantivo_azione tasti sia la strada da seguire.

Seguendo questa strada si giunge a:

Repeat keys – Ripetizione tasti

Chiaro ed elegante, no? Perché stare a discuterne??

Stiky keys – Permanenza tasti

C'è da notare che blocco tasti non è usabile. Questa funzione infatti opera in due modi: latch e lock. Nel primo (modalità serrata/serratura) si è premuto un tasto modificatore una volta e si aspetta il tasto da modificare: questo modo è da usare per combinazioni di due (2) tasti, p.e. Ctrl+S per salvare. Nel secondo (modalità blocco) si preme un tasto modificatore due volte e si aspetta un secondo tasto modificatore: questo modo è da usare per combinazioni di (3) tasti, p.e. Maiusc+Ctrl+S per salvare con nome. Tra le traduzioni mi era venuto in mente anche ancoraggio tasti....

Slow keys – Rallentamento tasti

Questa mi pare semplice ed efficace. Ed anche una buona traduzione.

Bounce keys – Pressione ravvicinata dei tasti

Qui la resa italiana non è ottima, ma l'originale non aiuta molto. Considerando che finisce nell'interfaccia utente come Abilitare la pressione ravvicinata dei tasti che è un controsenso visto che in pratica la si disabilita... Quasi quasi chiedo lumi su it.comp.accessibilita

Toggle keys – Tasti di commutazione

Questa traduzione esce fuori dal seminato, ma i tasti sono fisicamente presenti sulla tastiera, non si tratta di una funzione di accessibilità: non cioè si stanno commutando dei tasti, come lascerebbe intendere la traduzione commutazione tasti, ma sono i tasti a possedere in sé (e qui pare che stiamo facendo filosofia) la funzione di commutazione. La funzione è produrre un suono quando uno di questi tasti viene premuto.

Mouse keys – Mouse da tastiera

Come nome di una funzione mi pare ragionevole, no?

Parliamo di accessibilità - chiacchierata 2

Eccoci alla seconda puntata della notizie sull'accessibiità. Visto che di cose da dire che ne sono parecchie, passiamo subito ad analizzare la questione più spinosa della traduzione dei termini relativi all'accessibilità: le funzioni di accessibilità della tastiera. BTW notare l'uso del termine funzioni al posto di funzionalità che si richiama alla circolare dell'AIPA nel precedente blog :-P BTW2 l'AIPA non esiste più trasformatasi nel corso del tempo in CNIPA.

Lo scopo di tale funzioni è quello di permettere a chiunque di usare la tastiera.
Banale? Non tanto. Credetemi, non è una cosa facile usare una tastiera: nello scorso ciclo scolastico la mia mamma aveva in classe una bambina autistica, pesantemente autistica: niente rain man e capacità di vincere a Las Vegas o di tirare fuori illuminanti soluzioni matematiche, piuttosto completa scoordinazione dei movimenti, di ogni movimento, legato o derivato da quello che veniva definito caos sensoriale: per queste sue disabilità e la conseguente incapacità di modulare suoni in modo adeguato, questa bambina ha imparato nel corso del ciclo a comunicare tramite tastiera (si chiama comunicazione facilitata): un tutore (umano e addestrato) le forniva appoggio per il gomito, un guantino speciale le teneva le dita piegate tranne l'indice e lei doveva letteralmente fare precipitare il dito sulla tastiera covogliando i movimenti disordinati in un unico gesto.

Provate voi a tenervi il gomito con la mano sinistra e a far precipitare l'indice destro esattamente sulla lettere che volete battere: non è facile, vero?
Spero sia chiaro ora perché nello strumento di accessibilità della tastiera di GNOME ci siano così tante regolazioni diverse.

Il problema che a noi interessa ora è: come tradurre qui nomi così evocativi? Incrociando un po' di informazioni (pubblicazioni in rete, traduzioni di MS Windows, traduzioni di Sun per i manuali di GNOME) è venuto fuori quanto segue:

Repeat Keys

Non è esattamente una funzione di (sola) accessibilità. Si tratta della possibilità di tenere premuto un tasto per ripetere più volte l'immissione della stessa lettera. Si può regolare sia il ritardo prima di iniziare le ripetizioni, sia i caratteri da immettere per ogni secondo di pressione mantenuta. Buona traduzione, piuttosto di tasti ripetuti, è IMHO ripetizione tasti.

Sticky Keys

Utile a chi non possa premere contemporaneamente due o più tasti alla volta (per esempio la famosa combinazione Ctrl-Alt-Canc), permette di mantenere “attivo” un tasto modificatore come Maiusc, Ctrl o Alt fine alla pressione del tasto con cui attivare la scorciatoia. Il manuale Sun fa riferimento ad essi come a modificatori attivi. La Microsoft usa invece tasti permanenti.

Slow Keys

La pressione del tasto viene “accettata” solo il tasto è mantenuto permuto per un certo lasso di tempo, regolabile secondo esigenze. La traduzione di Sun è ritardo input, quella di Microsoft, ammesso che abbia indovinato, è tasti rallentati.

Bounce Keys

Là dove regna il Parkinson se ne sente la necessità. Attivando questa funzione, si evita che una pressione ripetuta dello stesso tasto porti all'immissione di tanti caratteri quante sono le pressioni. Se la mano vi trema pesantemente, è quello che fa per voi. La traduzione di Sun è pressioni ravvicinate, quella di Microsoft non c'è. Nel senso che non ho trovato analoga funzionalità nella versione di Windows usata come test; allo stesso modo una rapida ricerca di bounce keys su google riporta solo risultati inerenti a GNOME/Linux. Da considerare che tasti ripetuti non è usabile come traduzione, perché confondibile con quella di repeat keys.

Toogle Keys

I toggle keys sono usato anche da persone senza disabilità e sono quelli che fanno accendere i LED della tastiera: BlocMaiusc, BlocNum e BlocScorr. La funzione di accessibilità si limita ad emettere un suono all'accensione del LED (modificatore in funzione) e due allo spegnimento (disattivazione del modificatore). La traduzione di Sun è tasti di commutazione o tasti commutatori.

Come riferimento poi ci sono i requisiti 4 e 5 della Legge Stanca (spiacente per la mancanza di link, provvederò poi)

Enunciato requisito 4: se supportata la funzionalità di ripetizione di tasti, il ritardo, sia per la prima ripetizione per le ripetizioni successive, deve essere configurabile con un intervallo di almeno 2 secondi.

Enunciato requisito 5: il cambiamento di stato dei tasti selezionati o bloccati deve essere percepibile, oltre che visivamente, anche attraverso il tatto o l'udito.

Alla fine di questa panoramica, le idee possono essere molto confuse. Ovviamente si può pensare di tradurre le varie funzioni come tasti [ripetuti|appiccicosi|lenti|rimbalzati|commutati|mouse]: sarebbe una “buona traduzione” (traduzione che traduce, non spiega o semplifica), ma risulterebbe comunque evocativa e non chiara. Mi riferisco in particolare all'uso di tale traduzione nello strumento di preferenze di GNOME, così come nella documentazione dello stesso. Allo stesso modo traduzioni troppo libere rendono la vita del povero traduttore un inferno, costretto ogni volta a consultare il glossario per essere sicuro di ciò che scrive.

Volete una soluzione? Aspettate il prossimo post, mica pretenderete tutto e subito, no?

Parliamo di accessibilità - chiacchierata 1

La Repubblica riconosce e tutela il diritto di ogni persona ad accedere a tutte le fonti di informazione e ai relativi servizi, ivi compresi quelli che si articolano attraverso gli strumenti informatici e telematici.
Articolo 1, comma 1 della legge 9 gennaio 2004, n. 4

Cosa c'è di meglio di una legge dello Stato per chiarire un po' le traduzioni dei vari termini di GNOME che ruotano intorno alla a11y e per riprendere a scrivere su questo blog che ancora non ha un nome?

All'articolo 2 si recita:

Ai fini della presente legge, si intende per:

• «accessibilità»: la capacità dei sistemi informatici, nelle forme e nei limiti consentiti dalle conoscenze tecnologiche, di erogare servizi e fornire informazioni fruibili, senza discriminazioni, anche da parte di coloro che a causa di disabilità necessitano di tecnologie assistive o configurazioni particolari;
  
• «tecnologie assistive»: gli strumenti e le soluzioni tecniche, hardware e software, che permettono alla persona disabile, superando o riducendo le condizioni di svantaggio, di accedere alle informazioni e ai servizi erogati dai sistemi informatici.
  

Se ne deducono quindi tre importanti nozioni per il nostro glossario:

• accessibility va tradotto come accessibilità;
• assistive technology va tradotto come tecnologia assistiva:
• visto che vale ai fini di una legge direi che non serve nemmeno discutere su TP.

Ovviamente la legge poi scade un po' nel banale, ma questa è un'altra storia.

Andiamo allora a consultare a Circolare AIPA del 6 settembre 2001 (n. AIPA/CR/32) dal titolo Criteri e strumenti per migliorare l'accessibilità dei siti web e delle applicazioni informatiche a persone disabili.

Anche qui troviamo "tecnologie assistive" e varie altre definizioni:

• Per disabilità si intende qualsiasi restrizione o impedimento nel normale svolgimento di un'attività derivante da una menomazione. [...] il termine "accessibilità" va inteso quindi come la proprietà dei sistemi informatici di essere fruibili senza discriminazioni derivanti da disabilità.
  
• Le soluzioni tecniche, hardware e software, che permettono di superare o ridurre le condizioni di svantaggio dovute ad una specifica disabilità, vengono di seguito denominate "tecnologie assistive" o "ausili".
  
• Il grado più elevato di accessibilità si consegue attuando il principio della "progettazione universale", secondo il quale ogni attività di progettazione deve tenere conto della varietà di esigenze di tutti i potenziali utilizzatori. Questo principio, applicato ai sistemi informatici, si traduce nella progettazione di sistemi, prodotti e servizi fruibili da ogni utente, direttamente o in combinazione con tecnologie assistive.

La lettura di questa circolare è interessante, specie quando va a definire i criteri di accessibilità per le applicazioni. Ma prima di ciò, una quarta nozione importante da ribadire:

• quando non si voglia usare la parola accessibilità per ragioni varie (es. ripetuta più volte nella stessa frase o necessità di un sinonimo) allora la parafrasi accesso universale è ben più gradito di accesso facilitato.

La circolare inoltre ci definisce alcuni strumenti di tecnologia assistiva:

• screen reader per ciechi, con sintesi vocale o display Braille
• funzioni di ausilio per ipovedenti e disabili motori fornite dal sistema
• applicativo specifico di ingrandimento di schermo
• sistema di input vocale, con dettatura di testo e emulazione di comandi di tastiera e/o mouse
• ausilio per disabili motori, con tastiera e/o mouse alternativi

Ovviamente mi riservo di condurre altre indagini sul sito dell'AIPA, visto che, stando alla circolare "sta progettando la realizzazione di un sito specificatamente dedicato alla accessibilità. Nel frattempo, chiunque volesse inviare osservazioni, contributi, richieste, può inviare un messaggio di posta elettronica all'indirizzo accesso@aipa.it".