Lateralus - Schism

by Beaverton Historical Society

E venne il giorno in cui fu detto:

I've had students who turned in files that they've converted from OpenOffice with formatting problems that affects their grades

e prima di chiedersi «ma cosa hanno preso prima di pronunziare siffatta frase? tre mohito, due caipiroska e un ginger ale?» ci si domandò «ma che vuol dire turned in?»

Ebbene, noi siamo qui per dirimere, senza bisogno che consultiate un dizionario online, giacché noi l'abbiamo fatto per voi. To turn in: consegnare. Beh, ok, parlano di studenti, forse era facile da capire...

Ma noi siamo qui anche per approfondire, scavare, sezionare e ricomporre frase per frase, parola per parola, pensiero per pensiero.

Non si riesce a capire bene, giacché è stato scritto in dimensioni lillipuziane e non ho mica voglia di perdere altre diottrie¹, ma la citazione di sopra esce dalle labbra di qualcuno, forse donna, coinvolta in qualche modo in un ambito scolastico. Piccola nota di colore: tutte le altre citazioni fatte da gran timonieri di industrie sono recitate o registrate con voci maschili. La femmina, si sa, è maestrina.

by Simon Shek

L'evento che si sta descrivendo è più o meno il seguente. Uno studente scrive un documento con OpenOffice.org Writer, lo converte in formato Microsoft Word (chissà quale dei tanti, NdR), lo consegna alla insegnante (femmina, ovviamente, NdR) come compito. L'insegnante apre il documento con Microsoft Word (chissà quale versione, NdR) trova diversi errori nel documento, abbassa di conseguenza il voto al giovine. Il giovine, venuto a sapere del voto basso, espone le sue motivazioni all'insegnante e convengono che non era il compito ad essere errato, ma trattavasi di una o più incongruenze di formattazione. L'insegnante pronuncia la parola magica "estiqaatsi" e il giovane se ne va tenendo il voto basso.

Oddio, certo, ormai sono vecchio dentro e fuori, per cui è possibile che nell'attuale insegnamento delle arti e delle scienze si trattasse anche di una presentazione. Escluderei il foglio di calcolo e il database, dacché in questi casi a fare testo spero tanto sia la validità dei dati e non la formattazione. Spero.

Ma pensiamo al documento Writer per facilità. In fondo si parla di più di uno studente, per cui un cacchio di documento Writer prima o poi qualcuno l'avrà consegnato. Dove è il problema?

Intendo il vero problema, l'ingranaggio che scatta, la mattonella che balla, la cerniera che cigola. È forse OpenOffice.org il problema?

O piuttosto è una visione della vita ottusa e senza sbocchi che mal si addice, anzi che non si dovrebbe affatto avere in qualcuno che si professa insegnante e dovrebbe per questo in un certo qual modo non solo avere una apertura al mondo e alle differenze, ma anche ispirarla nelle giovani menti che per mestiere si trova a far crescere ogni giorno?

Un'altra citazione:

by Emily Barney

[...] each teacher she works with will be equipped and supported to help their students to walk away with the necessary tools to be successful in the academic, social and career environments. She is an educator because she believes that every individual can be successful. 

Chi lo dice? Beh, se si crede a ciò che si legge su Internet, la stessa maestrina di sopra² a proposito di se stessa su LinkedIn (parlando in terza persona...). Per cui, studenti di tutto il mondo, fatevi equipaggiare con lo strumento giusto. A scelta, il vostro cervello o un set di chiavi a brugola in cromo-vanadio in offerta da Castorama.

Sopratutto, non dimentichiamo mai e poi mai quanto possa essere deleterio per la salute psicofisica del fanciullo e del giovine il sistema scolastico italiano che ancora costringe i poverini a fare i compiti a mano e non offre delle pratiche caselle con crocetta.

[1] buciardo che sono...
[2] sì, l'ho letto il nome e ho cercato su goooooogle

TV Killed the Radio Star - parte 1

Come alcuni di voi di certo non sanno, è stato proposto un cambiamento nel modo in cui potrà in futuro essere inteso lo GNOME Desktop. I dettagli li trovate qui (e se non capite la differenza rispetto a prima, vuol dire che non conoscete GNOME e dovreste smetterla di dispensare consigli agli altri), i miei commenti... beh, lasciamo stare che è meglio.

Sulla base di ciò, se la nuova proposta va in porto, centinai e centinaia di applicazioni verranno di fatto incluse "ufficialmente" tra le GNOME Apps. Saranno tutte ugualmente valide? Soprattutto, cosa possono fare i rispettivi sviluppatori per migliorarle? Proviamo a rispondere a queste domande con un esempio pratico e sufficientemente dettagliato (e spero utile).

Avrei potuto scegliere come esempio il terribile Gwibber (che ce ne sarebbero di cose da additare), ma visto che sarebbe diventato solo un elenco di lamentele, ho preferito rivolgere l'attenzione a un altro programma, più utile alle nostre italiche genti: Tv-Player.

Per chi non lo avesse mai sentito prima, si tratta di un programma che permette di vedere gli stream offerti dalle televisioni via internet, prima tra tutte mamma Rai, senza passare per il browser e magari plugin di dubbia fama (come quello della Rai basato su silverlight/moonlight).

Funziona? Sì (mamma Rai permettendo). È una GNOME App "well behaving"? Proviamo a vedere.

Prima premessa: tecnicamente, per dichiarazione stessa degli sviluppatori, tv-player NON è un'applicazione GNOME, ma semplicemente GTK+.
Seconda premessa: non andrò ad aprire bug, per il semplice fatto che sono pigro :P
Terza premessa: questo non è un controllo di qualità del codice, ma solo la segnalazione di alcuni "standard" che magari tv-player non rispetta (nella versione che io ho installata, ovviamente)

File .desktop

Partiamo dal file .desktop, che poi è quello che serve per far sapere all'utente che l'applicazione è installata.

OK, lo ammetto, l'ho fatto apposta, solo per mostrare a quanti piccoli dettagli bisogna stare attenti in un file così piccolo:

• non localizzabile - tramite intltool è possibile contrassegnare alcune chiavi dei file .desktop come traducibili (usando un file .desktop.in da cui poi intltool genera il file .desktop finale), qui si ha un file .desktop fisso nella pietra
• chiave Version - dovrebbe essere non richiesta dalla specifica freedesktop.org, ma qui è addirittura usata male (non serve a indicare la versione dell'applicazione, ma della specifica per i file .desktop); se avessero verificato con l'utilità a riga di comando desktop-file-validate si sarebbe potuto ovviare questo piccolo problema
• percorso assoluto per l'eseguibile - il nome dell'eseguibile basta e avanza, inserire il percorso qui impedisce di installare in altri percorsi (mai sentito /usr/local?); ci sono modi per inserire un percorso (con gli autotool, non so come in Python), ma dovrebbe essere gestito nella fase configure+make (confrontare i sorgenti di alcuni moduli ufficiali di GNOME - per ora)
  
• icona - quanto fatto da tv-player è ammesso, ma è un modo vecchio, desueto e brutto di gestire l'icona che identifica l'applicativo; il file della icona dovrebbe essere installato nel tema hicolor (/usr/share/icons/hicolor/DIM/apps) e qui si dovrebbe indicare solo la named icon, senza percorso ed estensione, in modo da poter rendere l'icona temizzabile (importante per i temi a contrasto elevato, per esempio)
• assenza della chiave GenericName e della suggerita X-GNOME-FullName - per informazioni leggere qui; tra l'altro "TV Player" è un nome "generico", sarebbe opportuno trovare un nome figherrimo che permetta una qualche forma di branding, specie nella prospettiva del passaggio a GNOME Shell (ricordo le slide di un talk, forse di MPT, che parlavano anche della scelta del nome, solo che non le ritrovo... lazyweb, un aiuto?)
• avviso di avvio - mancherebbe anche la chiave StartupNotify, per fare in modo che la forma del cursore cambi, passando alla "clessidra" nel tempo che intercorre dal clic di avvio all'apparizione della finestra, ma in questo caso sarebbe necessario all'applicazione comunicare l'avvenuto caricamento e visualizzazione della finestra stessa.
  

Icone

Il mantra da seguire, in questo caso è: una brava applicazione non installa icone che non possano essere temizzate, una brava applicazione installa le "sue" icone in un "suo" percorso.

Tranne, come detto prima, l'icona dell'applicazione che dovrebbe essere istallata all'interno del tema hicolor - e men che meno in /usr/share/pixmaps, che deve morire :)

Una buona descrizione di perché e come correggere questo problema può essere trovata presso la pagina del GNOME Goal relativo fatto tempo fa.

Per le altre icone di TV Player solo qualche dubbio e suggerimento:

• Perché mai installare icone proprie per il volume? Esistono delle named icon apposta nella specifica di freedesktop (le varie audio-volume-*), non sono tra le stock delle GTK+ ma...
• ...ma, prima o poi le icone stock delle GTK+ andranno a morire, si spera nelle prossime versioni 3.x, per cui tanto vale usare quelle sia per il volume, sia per le altre icone presenti (per cui non gtk-delete, ma edit-delete, per esempio); questo ovviamente farà dipendere l'applicazione da gnome-icon-theme, ma è tutto da guadagnare, in prospettiva per il futuro.

Ah, se proprio volete o dovete inserire una icona "application-specific" (ossia una icona che non è tra quelle presenti in gnome-icon-theme e definita nella specifica indicata poco sopra), il modo "well behaving" di farlo è descritto qui.

Hidden file

Ultima annotazione, per oggi, riguarda un'altra specifica freedesktop e un'altra delle raccomandazioni da seguire per una brava applicazione GNOME: evitare di creare nella HOME degli utenti cartelle o file .$APPLICAZIONE.

Esiste infatti uno standard ben definito e documentato che dice come e dove piazzare i vostri file aggiuntivi per dati, configurazione, cache (e pare altro in futuro).

Le glib (e credo anche i relativi binding in Python) offrono delle comode funzioni per astrarre e gestire il tutto, evitando ogni forma di hardcoding dei percorsi assoluti o relativi. Motivazioni, vantaggi e altre indicazioni possono essere trovate qui, nella pagina wiki del relativo GNOME Goal.

Rispettando questo standard freedesktop è possibile evitare la proliferazione tipo disco di Petri di cartelle .$APPLICAZIONE nella home degli utenti, utilizzando le funzioni messe a disposizione di glib si guadagna la possibilità di rendere facilmente multipiattaforma la propria applicazione (che andrà a creare e controllare file e cartelle, senza preoccuparsi troppo del come, nella posizione giusta). Agli utenti, poi si permetterà di avere la possibilità di eseguire backup facili e non superflui, scegliendo per esempio di ignorare la cartella $HOME/.cache il cui contenuto è per definizione volatile e non fondamentale.

Trucchi, segreti e commenti

Se avete seguito tutti i link proposti prima vi sarete accorti di come anche molte applicazioni al momento ufficiali di GNOME ancora non seguono le indicazioni date. È pur vero che diverse di quelle applicazioni esistono da una decina d'anni, per cui è possibile che si tratti di strascichi ancora da correggere o tagliare via.

TV Player dovrebbe invece essere un'applicazione molto giovane, che avrebbe potuto rispettare sin da subito queste direttive o suggerimenti. Forse l'assenza di un unico punto di raccolta delle informazioni, il dover seguire con perdita di tempo personale diverse discussioni, mailing list, siti, blog, planet e quant'altro in modo da avere una visione d'insieme chiara è l'ostacolo più grande per chi sviluppa applicazioni di "terze parti". Esisterebbero la Integration Guide e la Platform Overview, ma in effetti sono documenti un po' datati; allo stesso modo sul wiki sono magari disponibili notizie più aggiornate, ma senza essere organizzate in un corpus organico.

Come preannunciato dal titolo questa è solo la prima parte, nella prossima (chissà quando mai apparirà, lo sapete che sono pigro e facilmente distraibile, specialmente in questo periodo d'inizio d'estate in cui cominciano a riapparire le te... vabbè, quelle cose lì che creano distrazione, mo' non è necessario specificare cosa sono, no?) andremo a spulciare la UI in cerca non già di un completo re-design (mica mi chiamo MPT, io) ma di altri aspetti e difetti che tolgono punti a questa applicazione.

Woodward e Bernstein non sono ancora morti (aka "Tutti gli uomini del deficente")

Premesso che

• di critiche a Wikipedia se ne possono fare a iosa come "accozzaglia di cose, priva di regole definite, di fonti accertate e controlli veri" (cit. ma non la trovate online);
• di critiche a Mozilla se ne possono fare a iosa come "ambiguo coacervo di soluzioni aperte e chiusure mentali" (cit. me medesimo che l'ho appena pensata);
• sempre siano benedetti Ogg (ora pro nobis) Vorbis (ora pro nobis) Theora (ora pro nobis) Speex (ora pro nobis) FLAC (ora pro nobis) che sono validi tanto ci piacciano, ma che se non li supportano i lettori portatili sono come una giornata umida, che aiuta con una signora ma non serve a un ca##o nella giungla;

la domanda che i Woodward e Bernstein de Noantri (ah, io faccio Robert Redford e tu Dustin Hoffman... e non venire a lamentarti che quello biondo e liscio sei tu) si sono domandati è "ma perché cavolo li vanno a dare a Wikimedia, i soldi?"

Wikimedia Foundation ha appena intascato 6.000.000 di dollari in donazioni, per cui a meno che i cravattari alla porta non avessero aumentato il tasso d'interesse di un 5 punti percentuali senza avvertire il cliente, non è che 100.000 dollari servissero urgenteme... no, 100.000 dollari sono 100.000 dollari, non si buttano MAI via. Ogni donazione è sempre e comunque bene accetta.

Il dubbio che nessuno di noi dubbiosi potrà mai sciogliere nasce da cosa c'è scritto qui (aggiungendo altre fonti inutili alla nostra complicata e altrettante inutile indagine) specie considerando ciò che lì è assente, depennato, damnatiomemorieizzato:

Mozilla has awarded a grant of $100,000 to the Wikimedia Foundation to help coordinate improvements to the development of Ogg Theora and related open video technologies [...] will be used to support the work of long-time contributors to the Ogg Theora/Vorbis codebase and related tools, such as libraries for network seeking. The improvements will be made over a 6 month period

Mozilla ha elargito una donazione di 100.000 USD a Wikimedia Foundation per aiutare la coordinazione dei miglioramenti allo sviluppo di Ogg Theora e delle correlate tecnologie aperte per video [...] verrà usata (la donazione NdT) per supportare il lavoro di contributori "long-time" al codice e ai relativi strumenti di Ogg Theora/Vorbis, come le librerie per il seeking su rete. I miglioramenti saranno apportanti in un periodo di 6 mesi.

Hmm. Bene. Cioè, io lo so che tutto il mondo è paese, che non esistono più gli idealisti di una volta e la mezza stagione chissà che fine ha fatto (dannata, io ero pieno di vestiti da mezza stagione). Lo so che uno non è che va a mollare in giro 100.000 USD solo perché crede nel futuro luminoso delle tecnologie aperte. Lo so.

Non mi stupisco, non mi altero, non faccio petizioni online, non buco siti per protesta, ma non posso fare a meno di puntare il dito verso un semplice, stupido, minimale, marginale, fondamentale, lampate fatto: la totale assenza di una semplice menzione di chi Ogg/Theora/Vorbis lo ha sviluppato e supportato da lungo tempo, la totale assenza di Xiph.org in tutti i comunicati e commenti da parte sia della Mozilla Foundation che della Wikimedia Foundation inerenti la questione (dai, pur di non linkare le pagine di xiph.org per le definizioni di Ogg e Theora hanno linkato quelle su wikipedia...).

Perché magari non sembra, ma non è che Ogg/Theora/Vorbis/etc etc etc sono nati dal nulla. Qualcuno li ha definiti e implementati e, guarda caso, quel qualcuno è la Xiph Foundation, anch'essa fondazione senza fine di lucro con il fine di spargere nel mondo il seme dell'apertura e guarda caso anche essa bene accetta a ricevere donazioni.

Se la Mozilla Foundation avesse voluto supportare in modo candidamente immacolato il formato Ogg/Vorbis/Theora, la donazione l'avrebbe potuta elargire alla Xiph Foundation, magari non interamente, magari congiuntamente, ma dal mio punto di vista sarebbe stato come dire: abbiamo implementato la possibilità di vedere video e sentire audio nel nostro browser, abbiamo un pacco di soldi che ci avanzano, ecco a voi un congruo riconoscimento per il lavoro svolto e vedete di continuate così che ci servite per rodere qualche altro punto percentuale, specie se ci fate funzionare meglio i video messi online da Wikipedia.

Per questo, a mio avviso, non dovrebbe essere chiamata "donazione", ma "accordo commerciale". Ed è come dire: noi, senza dover pagare royalties a nessuno abbiamo implementato nel nostro browser la possibilità di vedere video e sentire audio prima ancora che sia standardizzato con HTML5 e stiamo cercando in questo modo di forzare Ogg/Vorbis/Theora ad avere un posto di rilievo in tale futuro standard (forse), per lo meno per continuare a non pagare royalties (di sicuro), voi, o Wikimedia Foundation, voi siete l'unico sito che la gggente visita a mettere gli spezzoni video e audio nel formato Ogg/Vorbis/Theora, per cui eccovi un congruo assegno per continuare su questa strada, anzi magari per rendere la cosa ancora più endemica, facendo in modo che nei prossimi 6 mesi si possa creare negli internauti una necessità in più per usare Firefox o comunque aggiornare alla versione 3.1.

Che per carità, lo ha fatto Apple qualche mese fa quando ha anche lei rilasciato WebKit-Safari con un simile protosupporto al tag di HTML5 e poi sul _suo_ sito ha inserito i propri video con questo sistema, che lo ha fatto Microsoft quando ha partorito Silverlight e contestualmente ha aggiornato il _suo_ sito per usarlo in modo invasivo, ma che lo faccia Firefox in combutta con Wikimedia per farci vedere meglio questo... Dai, almeno la roba di Apple e Microsoft è un po' figa...

Cmq, visto che anche io ho a cuore che Ogg/Theora/Vorbis diventino bene accetti e largamente diffussi dentro e fuori la rete (anche se sulla rete spero di vederli al più presto con WebKitGtk e GStreamer), almeno per questo voglio buttarmi alle spalle per un momento tutta l'acredine sparsa finora e fare una proposta costruttiva: volete costringere le persone a installare Firefox per vedere i video su Wikipedia? Bene, pubblicate il Sex Tape di Pamela Anderson e Tommy Lee, che ormai sono passati anni ed è da considerare documento storico, almeno secondo quelli che mi pare siano i canoni di Wikipedia.

Non si può? Dite che lo vende Amazon? Hmmm... Hmmm... Un video live bootleg di Cristina Scabbia? Qualcosa degli Oliver Onions, tipo Sandokan, Orzowei? Cuba dei Gibson Brothers, dai!

Una talpa è solo una talpa?

Ah, ragazzi fortunati, che stasera non solo sono a casa perché mi sto dando a nuove forme artistiche cromatiche e pittoriche¹, ma non mi va neanche di raccontavi i fatti miei².

Cosa rimane? Beh, ovvio un paio di annunci per far sapere al mondo e a tutti gli amici di Internet le novità in anteprima di GNOME 2.23. Che gusto ci sarebbe altrimenti a compilarsi milioni e milioni di righe di codice, se non spifferare in anteprima e con inutile orgoglio (del genere dell'orgoglio che può avere un possessore di iPhone nei confronti di un possessore di, che so, Sony Ericsson Z320i)?!?

Allora procediamo?

Bene la prima succosa notizia è: habemus temorum supportum³!

Eravate lì pronti nuovamente a criticare, vero? E invece no. Con la rapida velocità degno dell'agguato di un giaguaro (oddio, quando scendo a metafore di così bassa fattura sappiate che non ho la forza di pensare) in quattro e quattr'otto abbiamo due specifiche freedesktop.org e una libreria di supporto per una cosa fondamentale come i temi per i suoni di eventi!!!

Fatta, utilizzata e benedetta, la nuova dipendenza esterna per GNOME libcanberra (il perché del nome non l'ho ancora capito, giuro), una libreria per eventi sonori che supporta le nuove specifiche XDG sound theming/naming, è stata molto abilmente e rapidamente usata nel modulo Audio del centro di controllo per stabilire quale suono riprodurre, per esempio, al login, o quando vi appare un'allerta di errore o altro.

Ora, ricapitolando e snocciolando i due precedente paragrafi per quelle persone prive di visionarietà sufficiente a leggere sotto le righe o di voglia di cercare su goooooogle, i seguenti punti sono fatti e non parole:

• esiste una specifica di freedesktop.org che stabilisce quale debba essere la struttura di un tema di suoni per eventi (tipo quella dei temi per le icone, per intenderci), la trovate qui;
• esiste una specifica di freedesktop.org che stabilisce i nomi di alcuni eventi audio utilizzabili dall'ambiente grafico e dalle singole applicazioni - una lista lunga, in verità - e i criteri per aggiungerne di nuovi (tipo quella delle icone, per intenderci), la trovate qui (sì, è lo stesso link, che posso farci);
• esiste un tema di suoni per eventi con alcuni suoni base, lo trovate qui (di nuovo, lo stesso link);
• esiste una libreria che implementa le due specifiche cui sopra, si chiama libcanberra
• esiste una libreria che semplifica la gestione degli eventi sonori in applicazioni GTK+, si chiama libcanberra-gtk ed è fornita nel pacchetto di libcanberra;
• esiste un modulo per le GTK+, sempre in libcanberra, che permette la riproduzione di suoni per eventi (tipo pulsante cliccato) anche senza che la vostra applicazione GTK+ lo abbia o debba specificare nel codice (così come fa adesso la deprecabile libgnomeui);
• esiste un minimo di interfaccia grafica in gnome-control-center per selezionare quale tema usare e quali suoni di eventi (non tra tutti quelli definiti dalla specifica, in verità) riprodurre.
  

Non solo. Anche Epiphany (ah, userà ancora Gecko per la 2.24) usa libcanberra, ma non ho capito per cosa, forse per comunicare via audio il completamento di un download e dello stesso umore sembrano gli sviluppatori di Empathy e forse altro.

Chiusura classica: per chi fosse interessato ad approfondire l'argomento, consiglio la lettura, in inglese, di questo annuncio da parte di Lennart Poettering, la persona dietro lo sviluppo di libcanberra.

Chiusura personalizzata: non chiedetemi schermate che le hanno già pubblicate altrove e sarebbe un controsenso, visto che parliamo di suoni e non di colori.

La seconda succosa notizia è che non c'è alcuna seconda succosa notizia.

[1] leggi "imbianchinaggio", ma su supporto antico, talmente polveroso che sono sicuro verrà fuori qualcosa a chiazze tipo spatolato, ma senza dover spendere euri e euri per la vernice adatta
[2] che a seconda di dove mi giro sono piattamente noiosi, compostamente tragici o murphianamente sfigatissimi
[3] OK, il mio latino è un bel po' arruginito..

Case histories

Secondo post della giornata, ma solo per comunicare una bella notizia che altrimenti magari passava inosservata.

Avete mai provato a navigare in quei siti web più o meno famosi che usano quei bellisssssimi menù in Flash pensati per essere trasparenti?

Vi siete accorti che il plugin Flash di Adobe non gestisce la trasparenza creando cacofonici (mi sa che questa parola non vuol dire quel che intendevo dire) effetti?

Vi siete accorti che il plugin Flash di Adobe non gestisce l'ordine corretto della sovrapposizione degli elementi Web2.0 creando impossibilità di uso pratico?

Avete imprecato per la questione e per il fatto che vi toccava usare Firefox 2.99.99.99 perché era l'unico che avevate a permettere di disattivare un plugin senza disinstallarlo? (e voi che avreste continuato a usare Epiphany senza capire come funziona...)

Bene, è il momento di cantare a squarciagola: Ramaya Ramaya Ramaya Ra Ra.

Benjamin "Bundeslighe" Otte ha appena annunciato che il sottostimato swfdec è il primo plugin Flash per GNU/Linux a supportare trasparenza e corretto ordine dello stack. Sia con Gecko che con WebKit. Oltre ad altre finezze.

Adesso, considerando che swfdec è anche rilasciato con licenza pubblica GNU, auspicando che funzioni bene sul 64 bit (cosa che ignoro, qualche info?), ricordando che è dipendenza benedetta di GNOME e che swfdec-gnome è parte di GNOME, quale altro impedimento impedisce ai distributori di includerlo come modulo predefinito nei loro prodotti out-of-the-box? La gente vuole il Flash? Intanto dategli swfdec, se poi non gli basta permettegli di sostiuirlo con quello di Adobe. Facile, no? Utile, no?

Oh, sse you in september, Gnash.

Noi togliamo il fumo della vostra cucina a gasse

La vostra webcam non funziona? È colpa di linux. La vostra banca non vi fa accedere online? È colpa di linux. Il vostro sito web p0rn0 preferito non si vede bene? È colpa di linux.

La vostra connessione wireless non si connette? È colpa di NetworkManager e fate meglio a usare Wicd.

A parte che, salvo decisioni future dell'attuale Ministro del MIUR, il condizionale non è estinto; a parte che, per logica e coerenza, dovreste continuare a dire "è colpa di linux"; a parte tutte le limitazioni del caso e i problemi che effettivamente attanagliano l'attuale versione stabile (0.6.x); a parte tutto ciò, dunque, prima di esaltare wicd e proporlo per il Premio Nobel, avete riflettuto sul fatto che NetworkManager non è che non funziona, ma è diversamente funzionante?

Andiamo per un momento alle relative pagine web prima linkate e leggiamo:

• wicd è un gestore di connessioni con e senza filo che fornisce un'interfaccia per connettersi alle reti fornendo una pletora di impostazioni;
• NetworkManager è ... uh... beh... ecco... OK, non c'è scritto a chiare lettere, ve lo riassumo io: è un framework per la gestione semplificata delle connessioni, principalmente senza filo.
  

NetworkManager è sì un gestore di connessioni, ma è anche una infrastruttura che permette agli sviluppatori di software di far sapere alla propria applicazione se in un determinato momento il sistema ha una connessione di rete oppure no e agire di conseguenza. Il tutto anche tramite una comoda e agnostica (dal punto di vista dell'ambiente grafico e toolkit) interfaccia DBUS.

Se proprio volete un colpevole, e se usate Ubuntu, magari dovreste rivolgere il vostro speranzoso sguardo ai pacchettizzatori del kernel della appena citata distribuzione, i quali includono driver per schede wireless non supportate da NetworkManager 0.6 (driver che non implementano WEXT in modo corretto, quindi che non funzionano con wpa_supplicant, quindi con NM): il compito di un distributore sarebbe assemblare i pezzi con un minimo di raziocinio... Ah, pare che anche questa patch abbia le sue belle colpe. E non lo dico io, lo dice chi NetmorkManager lo sviluppa.

Ma torniamo a bomba. NetworkManager è stato pensato come "trasparente". Basandosi su HAL e DBUS, la speranza era fare in modo che la connessione alle reti disponibili fosse del tutto indolore per l'utente, fatto salvo scegliere quale tra le varie disponibili. Una volta fatta la scelta, NM si sarebbe gentilmente occupato di segnalare alle applicazioni che era disponibile una connessione di rete e comportarsi di conseguenza. Evolution, Epiphany e Liferea per esempio passano automaticamente in modalità "fuori rete" quando NM li avvisa che non c'è rete. E viceversa quando la rete diventa disponibile.

Al momento io non ho un portatile, ma nel caso mi piacerebbe assai se il comportamento fosse questo.

Al momento io non sto sviluppando software che richieda una connessione di rete, ma nel caso mi piacerebbe molto se potessi semplicemente monitorare i messaggi DBUS per sapere se la rete c'è oppure no o se debbo cambiare indirizzo senza che l'utente abbia una "interruzione di flusso".

Al momento io non sto amministrando un sistema, ma nel caso mi piacerebbe tanto se potessi gestire il tutto anche traminte PolicyKit e GConf (con i loro bei rispettivi sistemi di policy e lockdown).

Nel frattempo continuo a credere che NetworkManager sia pensato meglio, a sperare che possa al più presto funzionare in modo completo, a pregare che i pacchettizzatori di Ubuntu non inseriscano patch e modifiche a ca##o di cane senza rispettare la filosofia del progetto.

PS voi fate come volete, per carità, ma se aggiungete un commento a questo post dicendo "eh, sì, però pensa al povero utente non smaliziato che ha una scheda wireless non supportata..." e simili, li cancello.

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

Sono indeciso...

Secondo voi questo è un pesce d'aprile?

Anche perché se non sbaglio negli ultimi giorni sono continuati i commit per compilare con Gecko... Ma che senso avrebbe postare il messaggio sulla desktop devel list? Bastava fare l'annuncio sul blog, no?

Update: questo e questo sono sicuro che lo siano... beh, lo spero...

Quello che le note non dicono

Uff... pensavo che l'immortale capolavoro di Luigi Zampa fosse meno conosciuto... o per lo meno che Guido Tersilli oscurasse completamente la commovente storia di Amedeo Battipaglia...

Ma tant'è. Ecco quindi l'elenco degli indizi che avevo sparso qua e là:

• schermata di Cheese - sulla foto scattata in basso a destra c'è sovraimpresso un fotogramma del film, lo stesso che trovate su it.wikipedia; si distingue abbastanza chiaramente Claudia Cardinale
• schermata di Orologio - nella finestra di chat fingo di parlare con Amedeo Battipaglia, personaggio interpretato da Sordi, e chiedo del volo di Carmela, personaggio interpretato dalla Cardinale
• schermata di Evolution - nei tre appuntamenti ritornano i nomi dei persoggi o interpreti: Amedeo, Cardinale, Claudia

Già che ci sto, ecco anche l'elenco delle stronzate stupidaggini che c'erano nelle note di rilascio della 2.20:

• schermata di Evolution - segnalazione del funzionamento parziale del plugin "avvisa allegati mancanti"
• schermata di Evolution 2 - compleanno di Asia Argento (era l'unica persona Italiana sufficientemente famosa il cui compleanno cadesse in quelle date)
• schermata di Evince - Stefano Belisario, stelio@fave.net, aranciata amarissima e "porto i dischi" non vi dicono niente niente?
• schermata di Totem - il video di Geek Geek
  
• schermata di gnome-screensaver - ma l'avete letto il messaggio? Dio che passa per chiedere un consiglio e non mi trova?!?!

Per concludere, un elenco di cose belle qua e là che le note di rilascio di GNOME 2.22 non dicono, ma che invece sono importanti anch'esse:

• glib - introduzione di GChecksum, un'API per il calcolo del checksum di una sequenza arbitraria di byte usando gli algoritmi MD5, SHA-1 e SHA-256;
• glib - introduzione di GTest, un'API per fare eseguire al vostro codice test automatizzati;
• libsoup - una completa riscrittura (con tanto di API break rispetto alla versione 2.2) della libreria di GNOME per HTTP lato client/server, che va a rendere questa libreria più glib-style (uso di GObjects e del main loop di glib);
  
• dbus - nuova serie 1.2.0 (che però si chiama ancora 1.1.20 perché non hanno fatto in tempo a chiedere a tutti i contributori il permesso per cambiare licenza...)
  
• evince - nuovo backend per il file PostScritp, libspectre;
• evince - i backend per i tipi di file supportati sono ora moduli caricabili e possono essere forniti "dall'esterno";
  
• epiphany - riscrittura del livello intermedio tra l'applicazione e il backend per il rendering dell'HTML, in modo da non essere più legato design di Gecko/Mozilla (sì, epiphany è pronto per WebKit, c'è solo da vedere quando WebKit sarà pronto [leggi stabile e perfomante] per GNU/Linux/GTK+);
• gnome-keyring - certificati X.509, chiavi RSA e DSA, in pratica completo supporto ai principali sistemi di memorizzazione di certificati;
• gnome-keyring - agente SSH integrato con la sessione (in pratica vi autenticate al login e lui pensa a fornire la vostra password ssh quando ce n'è bisogno... comodo, ma state attenti alle applicazioni maliziose);
• seahorse - supporto completo a gnome-keyring;
• gnome-settings-daemon - precedentemente parte di gnome-control-center, è il demone che si occupa di gestire varie impostazioni del vostro GNOME facendo da tramite tra GTK+ e GConf; la novità è proprio nel fatto che è stato separato perché sarebbe servito al nuovo GDM, ma dovremo aspettare la 2.24 per goderci i benefici;
• nautilus - gestione dei supporti rimovibili in base al contenuto e semplificata associazione all'applicazione adatta per mezzo di speciali tipi MIME (in pratica: Nautilus riconosce il tipo MIME fittizio del vostro DVD video, Totem dichiara che supporta quel tipo MIME, così quando inserite il DVD Totem parte senza che voi dobbiate scrivere astruse righe di comando in gnome-volume-manager);
• GStremer - pletora di correzioni e novità, spostamento di plugin giudicati maturi da -bad a -good (multifile, spectum, equalizer, lpwsinc, bpwsinc, videocrop, osxvideo, qtdemux, waveform) e nuovo plugin per usare GIO
  

Una nota personale: le migliorie a libsoup e gnome-keyring sono veramente interessanti, specie dal punto di vista degli sviluppatori. Il secondo, in particolare, sarebbe pronto per essere sfruttato come si deve, non solo per funzioni fornite, ma anche per la maniacale cura posta nella sicurezza del tutto (una per tutte: memoria RAM); peccato che i due moduli che se potrebbero avvantaggiare (epiphany per memozirrare le vostre password di accesso ai servizi web, evolution-data-server per password, certificati e firme) non lo facciano (epiphany perché si deve appoggiare a Gecko che usa un suo metodo, si spera in WebKitGtk, che tra l'altro ha appena inserito libsoup come alternativa a libcurl per il trasporto HTTP; evolution-data-server ce l'ha ma opzionale... predefinito e unico sarebbe terribilmente meglio).

A proposito di Gecko e WebKit.... mi sa che tra poco vedremo guerre sante e fratricide, ma questa è un'altra storia...

Cestini scriteriati

Aggiornamenti pratici dal fronte GIO/GVFS: prove alla mano, anche il cestino diventerà standardizzato.

Al momento il cestino di GNOME è collocato in $HOME/.Trash/ e contiene solo i file.

La specifica di fd.o relativa al cestino invece prevede che non solo i file vadano collocati in $XDG_DATA_HOME/Trash/files/, ma che ci sia anche una bella directory $XDG_DATA_HOME/Trash/info/ che, per ogni file cestinato, presenta un file tipo

[Trash Info]
Path=/percorso/al/file/eliminato.txt
DeletionDate=2007-10-25T21:50:10

Un piccolo «Urrà!»

Tromboncino lanciabombe

Prima che GNOME 2.20 finisca sui vostri computer e un'ondata di indignazione affoghi il mio client email, nella traduzione di alcune parti dell'ambiente grafico e del manuale utente, troverete una piccola modifica nella traduzione italiana.

Dite quindi addio, con cuore da traduttore, alle "icone di avvio" e salutate con gioia i "lanciatori".

Le motivazioni del passaggio sono prettamente tecniche.

Numero 1: in originale si chiamano "launcher" e sono definiti e glossariati nel manuale per l'utente di GNOME

Numero 2: non sono proprimente delle icone, anche se a volte prendono aspetto e consistenza di icone. Niente vieta a un launcher di essere una voce di menù nel menù Applicazioni.

Numero 3: non sono propriamente di avvio: servono per lo più ad avviare applicazioni ma possono anche aprire posizioni come cartelle locali e remote, file, pagine web, sezioni di manuale, ecc...

Numero 4: le linee guida del Translator Project italiano dicono che bisogna "tradurre, non spiegare"

Numero 5: la traduzione di un termine dovrebbe essere, quando possibile, il più vicino possibile all'oginale, sempre secondo le linee guida del TP

Numero 6: per quando elencato qui sopra, lanciatore è la traduzione più opportuna.

Numero 7, 8, 9: non rompete troppo, è così e basta :-)

Update mi ero dimenticato di scrivere che, stando a garzantilinguistica.it le traduzioni di launcher sono

1. dispositivo di lancio
2. catapulta
3. lanciarazzi
4. tromboncino lanciabombe
   

Alcuni di noi (traduttori, NdR) erano abbastanza propensi per "catapulta"... Il che spiega molte cose sul livello di professionalità dei traduttori di GNOME... e non sapete come scrive Milo su jabber...

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

Sinonimo di genuinità e garanzia del consumatore

Per replicare alle numerose manifestazioni affetto e gratitudine ricevute, visto che la data del 19 settembre si avvicina e qui sembra non muoversi nulla, ecco un paio di trucchi per rendere molto più tanghera (e figa) la vostra futura installazione di GNOME 2.20.

Attenzione, è materiale confidenziale e io negherò di aver pubblicato questo post.

Fatemi uscire da qui

Update: all'ultimo momento, cioè cinque minuti prima di preparare il pacchetto per la 2.20, ma a quanto pare il cambiamento è stato accettato! Niente più bisogno di andare a pasticciare in /usr

A causa di una banale dimenticanza e delle limitazioni imposte (freeze) dello schema di rilascio di GNOME, il pacchetto gnome-icon-theme versione 2.20.x installa una doppia versione dell'icona "gnome-logout": la vecchia icona a forma di porta aperta con la freccia rossa e la nuova, una sagoma umana che "si muove"... OK, descritta così parrebbe veramente orribile, ma sinceramente e personalmente la trovo gradevole, un po' come tutte le cose nuove che non fanno proprio schifo.

A causa di questioni di precedenze che non vi sto a spiegare, è possibile che la vecchia icona venga presa e usata, specie se deve essere disegnata a 48×48 pixel.

Se avete permessi di amministratore, potete eliminarla senza colpo ferire con comandi del tipo:

$ cd $PREFISSOINSTALLAZIONE/share/icons/gnome
$ sudo rm 16x16/apps/gnome-logout.png
$ sudo rm 24x24/apps/gnome-logout.png
$ sudo rm 48x84/apps/gnome-logout.png

o con ogni altro trucco/metacarattere/find che vi venga in mente. Attenzione: nella serie 2.20 ci saranno "due" icone dal nome gnome-logout. Deve essere tolta solo quella sotto la directory apps, non quella sotto actions (questa seconda infatti è la nuova icona, se eliminate anche quella, allora la questione è accademica).

Ovviamente, il procedimento andrà ripetuto ogni volta che installerete o aggiornerete gnome-icon-theme, almeno per altri 6 mesi.

Appiccicami tutto

Per questioni analoghe a prima (a cui aggiungo che discutere con jimmac talvolta è difficile e con dobey sempre e comunque impossibile - BTW ma la Novell lo ha cacciato?), non è stato possibile aggiornare alcune delle icone dei simboli (emblems) che rendono Nautilus tanto figo. In questo caso, oltre al disegno "vecchio", c'è anche la questione delle dimensioni delle icone, recentemente modificata nel codice di Nautilus stesso e nella organizzazione di gnome-icon-theme.

Qui possiamo fare qualcosa anche senza invocare per forza i poteri della super mucca. Basta che vi scaricate questo pseudo-tema che ho premurosamente preparato e lo estraiate nella directory $HOME/.icons/ (quella in cui stanno le icone locali). Per le solite ataviche questioni di precendenza e dimensioni, verranno prese le icone locali, a meno che non zoomiate troppo,

Il risultato - i più accorti, o paranoici, lo avranno già notato[1] - è visibile nella schermata del precedente post relativo al rubberbanding. Osservate meglio i simboli applicati alle cartelle visibili e... stupitevi!

Se proprio volete zoomare tanto... beh, ma debbo spiegarvi tutto io? Andatevi a leggere le specifiche dei temi di icona e vedere se riuscite anche voi a essere dei piccoli wannabe-guru.

[1] cioè, dovreste essere come quelli che hanno visto l'icona del bluethoot su delle immagini ufficiali dell'iPhone e hanno decretato che il chip c'è ma è disattivato...

Do ut des, Clarissa

Se io vi rendo noto che in GNOME 2.20 finalmente sarà possibile trascinare senza problemi file da una finestra di File Roller a una di Nautilus (scrivania compresa), voi ricambiate il favore e mi linkate nei commenti un bel file PDF in italiano che abbia del moduli (o form) da riempire? Mi serve per le schermate delle note di rilascio, mica ne faccio collezione...

Vi ho fatto un'offerta che non potete rifiutare. Dunque proseguo con un personale comunicato ufficiale:

Nella prossima versione di Nautilus (e comunque già presente sul TRUNK del repository svn) sarà implementato il Direct Save Protocol per X Window System (o XDS in breve). In pratica, sarà possibile far corrispondere una azione di trascinamento tra applicazione e file manager con una azione di salvataggio/creazione di un nuovo file. Tale funzionalità correggerà finalmente un annoso e storico problema di comunicazione tra il file manager Nautilus e il gestore di archivi File Roller, ma potrebbe anche aprire interessanti orizzonti Update (p.e. selezione di testo, trascinamento del testo sulla scrivania o su una finestra del file manager e creazione di un nuovo file di testo contenente quanto selezionato e trascinato) Mi dicono dalla regia che la cosa è già possibile, direi che debbo capire meglio a che serve 'sto XDS...

Alexander Larsson, maintainer del file manager ha dichiarato: «I've commited XDS support losely based on Amos patch. However, it doesn't yet support dnd to the list view.»

OK? Ora tocca a voi. Fuori i PDF con modulo.

One more thing

Apple acquista CUPS....

....speriamo almeno che aggiornino la pessima grafica dell'interfaccia web e del logo...

Gnacchisnà

Continua la saga di post su xdg-user-dirs. Se la Disney Italia ha chiamato saga wizardsofmikeys non vedo perché non possa farlo io con i post.

Io però ho un buon motivo per continuare: ora anche il buon GNOME Panel supporta xdg-user-dirs.

Così come un buon libro, anche xdg-user-dirs ha diversi punti di vista, diversi piani di lettura. Ovviamente è un software, quindi i piani sono solo 3: sviluppatori, amministratori, utenti.

La parte sviluppatori spero sia stata abbastanza chiara nella parte precedente. Se usate le glib in via di sviluppo, le future 2.14.x, una funzione vi basta e vi avanza, se no dovete fare copia e incolla del codice da xdg-user-dirs stesso (che poi è quello che c'è in Fedora 7).

Per amministratori

Se siete amministratori, o vendor, avete due file con cui modificare il comportamento: /etc/xdg/user-dirs.conf e /etc/xdg/user-dirs.default.

Il primo definisce semplicemente se usare xdg-user-dirs e quale encoding usare per il nome delle directory (come predefiniti, rispettivamente YES e UTF-8).

Il secondo definisce quali directory e con quale struttura creare le cartelle predefinite per tutti gli utenti. Per struttura intendo che è possibile sia mettere tutte le varie cartelle in $HOME, sia fare qualcosa in stile Windows tipo:

MUSIC=Documents/Music
PICTURES=Documents/Pictures
VIDEOS=Documents/Videos
[...]

La sintassi del file è abbastanza semplice; le chiavi riconosciute sono, al momento APPLICATIONS, DESKTOP, DOCUMENTS, DOWNLOAD, MOVIES, MUSIC, PHOTOS, PICTURES, PROJECTS, PUBLIC, SHARE, TEMPLATES, VIDEOS; i valori delle chiavi sono i sono percorsi delle cartelle relativi alla directory $HOME e per garantine la localizzaione devono essere gli stessi delle chiavi, sia con prima lettera maiuscola (p.e. "Music") che minuscola (p.e. "music").

Questo vuol dire, ad esempio, che volendo posso definire un qualcosa tipo:

MUSIC=Data/Music

per il quale solo il nome della directory Music potrà essere localizzato, non quello della directory Data, in quanto quest'ultima risulta "sconosciuta". Ovviamente non ho ancora provato se la cosa funziona veramente e come, specie se aggiorno la configurazione di sistema dopo aver creato le directory nella home dell'utente.

Per l'utente

Era ovvio e prevedibile che un sistema del genere fosse progettato per essere configurato anche dall'utente. anche qui abbiamo due file per la configurazione entrambi posti in $HOME/.config (ossia nella directory speciale $XDG_CONFIG_HOME).

Il primo dei due file user-dirs.locale memorizza semplicemente il codice dell'attuale localizzazione delle directory.

Il secondo file, user-dirs.dirs fotografa lo stato attuale. La sintassi è lievemente differente:

XDG_DESKTOP_DIR="$HOME/Scrivania"
XDG_DOWNLOAD_DIR="$HOME/Scaricati"
XDG_TEMPLATES_DIR="$HOME/Modelli"
...

A sinistra del segno di uguaglianza la variabile ha un prefisso e un suffisso, a desta del segno vi è il nome, completo di percorso, di una directory (che deve esistere) a cui la variabile punta.

Le modifiche che si possono apportare a questo file sono le stesse di prima: è possibile quindi aggiungere, nel limite dei valori riconosciuti, dei percorsi oppure modificarli, con la differenza che la directory che si sta aggiungendo o modificando deve già esistere. Al momento non esistono strumenti grafici per la modifica della configurazione.

Le modifiche applicate dall'utente alla struttura sono conservate quando, al login, vengono aggiornati i nomi nel caso di cambio di lingua scelta.

Per i criticoni

Appunto mentale: scrivere qui qualcosa di sarcastico al punto giusto per controbattere tutte le stupide (ma senza dire che sono stupide, definirle magari superficiali) critiche tipo "tanto difficile crearsi 3 o 4 cartelle?" oppure "un’obbligazione che non mi è mai piaciuta, e che non uso" oppure ancora "se faccio una foto alla mia carta d’identità dove la metto? $immagini o $documenti?".

Piatto ricco mi ci ficco

C'è un'aspetto che forse nessuno ha considerato nella "guerra dei desktop search engine": il fatto che, per come sta andando avanti ora, ne sopravviverà soltanto uno.

Sì perché al momento, in base a quanto so o ho letto in giro per la rete, l'unico punto su cui i vari desktop search engine stanno lavorando di comune accordo (o per lo meno l'unico punto comune a cui si possono riferire) è l'interfaccia per la definizione delle interrogazioni, cioè il progetto fd.o Xesam.

La possibilità di avere una comune "interfaccia" per effettuare una interrogazione è ovviamente cosa buonissima e giustissima, tanto per l'utente finale che cerca nei propri oggetti[1], quanto per gli sviluppatori che volessero rendere la propria applicazione "cercabile"[2]. Se poi tale interfaccia mi permettesse di scrivere interrogazioni complesse e flessibili come queste, allora tanto meglio[3].

Il punto è che ogni altro componente del search engine non è condiviso: non è condiviso il database in cui andare a cercare ciò che è indicizzato (e quindi debbo mantenere aggiornato un database per ogni search engine) e non sono condivisi gli estrattori che permettono di estrarre dati e metadati dagli oggetti (e quindi posso avere oggetti non supportati o supportati in modo diverso a seconda del search engine).

Tali mancanze precludono la modularità che da sempre contraddistingue i sistemi liberi come GNU/Linux, i vari *BSD, i vari *Solaris, modularità per la quale se un "pezzo" del sistema non mi piace, fosse esso il kernel, l'ambiente grafico, la shell, il browser, posso cambiarlo a costo tendente a zero.

Se io passo da una distribuzione di GNU/Linux a OpenSolaris, in gran parte non mi accorgo della differenza, ancor di meno me ne accorgo se entrambi usano per esempio GNOME come UI. Se io passo da Beagle a Tracker, o da un futuro GNOME con Tracker a un futuro KDE con Strigi, come prima cosa debbo reindicizzare tutti i miei oggetti - e non è detto che la cosa richieda poco tempo, anzi.

Analogo discorso per gli estrattori: guardando la questione con occhio lungimirante, non è possibile che il search engine fornisca estrattori per ogni tipo di file. Il search engine dovrebbe fornire una API o dello specifiche per far sì che sia l'applicazione stessa a fornire l'estrattore. La API, le specifiche e la disponibilità degli estrattori dovrebbe essere comune a tutti i search engine. Punto.

Se non è chiaro dove l'ultimo paragrafo volesse andare a parare, nell'attuale situazione, anche ammettendo che il search engine fornisca un modo per installare nuovi estrattori, cosa utilissima, ci troviamo nella condizione in cui ogni search engine dovrebbe/potrebbe avere, per esempio, un suo estrattore per i file JPEG fornito "out of the box" (il formato JPEG è un formato comune, non è proprio di una certa applicazione, quindi è pacifico che sia il search engine a installarlo) e dovrebbe/potrebbe avere anche un estattore per i file XCF fornito da GIMP. Non solo quindi mi troverei con N implementazioni diverse, con N numero di search engine disponibili, dell'estrattore per i file JPEG, ma gli sviluppatori di GIMP dovrebbero sviluppare N diversi estrattori.

Se dipendesse da me, accanto a Xesam cercherei di portare avanti anche una definizione e implementazione comune degli estrattori, qualcosa con una struttura simile ai plugin di GStreamer: un pacchetto extractors-base con gli estrattori di formati comuni/liberi come potrebbero essere i formati di immagini PNG, JPEG, TIFF, SVG, i formati di OpenDocument, i file di testo semplice, i file HTML, i file PDF e cose simili, e un pacchetto extractors-extra con altri estrattori per formati meno comuni e/o meno liberi come i documenti di MS Office o comunque che richiedano librerie o programmi di supporto esoterici. Il fatto che la definizione degli estrattori è comune permetterebbe poi agli sviluppatori di fornire estrattori per il formato proprietario usato dalla loro applicazione (cosa apprezzabile di certo da chi scrive software non libero, come potrebbe essere MathLab; ma ci pensate a cercare con Nautius una definizione di matrice MathLab?!?!?).

Sforando poi nel fanta-development, con estrattori comuni e interrogazioni comuni, non sarebbe possibile per un search engine interrogare direttamente il database di un altro search engine per costruire il suo, invece di scansionare tutti i file??? OK, questa forse è troppo azzardata...

Conclusioni, ammesso che se ne senta la necessità

Prima una premessa: quanti di voi seguivano lo sviluppo di GNOME nel 2002? Quanti di voi hanno mai senti parlare di Bowie J. Poag? Nel dicembre di quell'anno codesto Bowie postò sulla devel list di GNOME la proposta di un "desktop riavvolgibile". Ovviamente Mr. Poag altro non era che un troll. Però Apple promette per la prossima versione di OSX una applicazioncina dal nome Time Machine, che... beh, installatevi tutti i vari plugin di GStreamer e guardatevi il video nella pagina, è molto più chiaro di molte parole.
Seth Nickell provò tempo fa a implementarlo in GNOME, come parte di un ambizioso progetto dal nome Storage, ma questo era talmente carico di funzionalità che cadde nel dimenticatoio prima ancora di diventare un minimo usabile. BTW ma che fine ha fatto Seth?!?!?

Con la prossima versione di MacOS Apple darà quindi ai suoi utenti qualcosa di molto simile a quello Storage sognato da molti pochi anni fa. Apple può farlo, non perché sia più brava, ma perché deve vedersela solo con se stessa: è lei che decide quale search engine fornire, quale file sytem, quale interfaccia per gli sviluppatori, non ha "competizione" tra diverse istanze. Ho deciso di inserire questa funzione e lo faccio in questo modo.

Per il software libero è diverso. Non che sia peggio, a me piace pensare e avere la possibilità di scegliere tra diversi progetti con stesse finalità, anche perché le migliorie di uno si riflettono nell'altro, ma, come il progetto freedestkop ci ha insegnato, è necessario permettere l'interoperabilità affinché tutti possano trarre vantaggio da questa varietà di contributi.

-------------------
[1] nel senso di non solo documento o immagine, ma anche conversazioni IM, contatti, calendari...
[2] e badate bene che per applicazioni "cercabili" intendo cose come F-Spot o Rhythmbox: se ho già un motore per definire delle query con cui limitare gli oggetti mostrati, perché mai dovrei scrivere nuovo codice?
[3] ovviamente per permettere agli sviluppatori di costruire applicazioni cercabili, il search engine deve permettere interrogazioni siffatte.

Ignorante nel senso che ignora

I miei lettori più accorti, notandolo tra le pieghe dei miei scritti, sapranno già che la mia mamma è un'insegnante. Magari in barba alla legge sulla privacy, rivelo che lavora presso la scuola 126-esimo circolo Iqbal Masih.

In questo post, però, non parliamo della mia mamma, ma del sito della scuola presso cui la mia mamma lavora. Prima però di visitarlo e di parlarne, vi consiglio la lettura di questo post del sempre arguto Paolo Attivissimo.

Avete letto il post di Paolo? Avete letto la nota in fondo alla homepage del suo sito? Bravi! Ora è il momento di cantare a squarciagola: «Ramaya, Ramaya, Ramaya, Ra Ra» - fine dell'intermezzo idiota

Ora potete iniziare a visitare il sito della scuola. Addentratevi pure nei meandri di una catalogazione che non capisco, aspettate su linee a 56k che le immagini vengano scaricate e infine meravigliatevi se invece di aprirsi un collegamento vi viene scaricato un file con estensione misteriosa.

A questo punto ripensate alle parole di Paolo. E piangete lacrime amare.

Commenti.

• Partiamo dall'ovvio: l'uso dei frame e l'assenza (!!!) di un titolo. Peccati veniali? Non tanto visto che al supermercato, nella corsia della frutta e verdura, quando ho chiesto «Signora, i frame?», l'arzilla vecchietta di turno mi ha risposto «Nessuna pietà!»
• Passiamo all'inutile: le migliaia di immaginine tanto caaaaarine che animosamente si animano qua e là.
• Deviamo sul raffinato: l'assenza di una qualsivoglia struttura, i collegamenti di colori diversi, l'uso di font a caso, quel ca##o di sfondo carta arricciata che ne ho visti a sufficienza negli ultimi dieci anni da essere a posto per i prossimi 30.
  
• Concludiamo con il tragico: i file MHT (che mi fanno dire, parafrasando una frase pronunciata di fronte a un recente reality a cui partecipa gente di un certo livello: «Ma chi straca##o sono i file MHT?»)
  

Per chi, come me, non sapesse cosa sono i file MHT, viene in aiuto il file MHT stesso, che nelle sue prime righe presenta queste indicazioni:

Questo documento è una pagina Web in file unico, nota anche come archivio Web. La visualizzazione di questo messaggio indica che il browser o l'editor in uso non supporta gli archivi Web. Scaricare un browser che supporti gli archivi Web, come Microsoft Internet Explorer.

Ovvio, no. Insomma, è molto più semplice fare un archivio web con il caro vecchio Word invece che imparare come funziona Internet. Chi vuoi che non usi Microsoft Internet Explorer? Beh, chi si basa un altro sistema operativo come MacOS, o GNU/Linux, o i vari *BSD, o Solaris, oppure chi pur basandosi su Microsoft Windows ha scelto, per buoni motivi, di utilizzare un altro browser come Mozilla, Firefox, Flock, Opera, Safari, Konqueror, oppure ancora chi non usa un computer in senso classico ma un dispositivo mobile come il Nokia 770 (mi sa che ne è uscito uno nuovo, vero?).

Come è possibile che avvengano certe cose? - vi starete domandando. Eppure - starete esclamando - sono stati spesi milioni e milioni di dindi per rendere informaticamente alfabetizzati gli insegnanti italiani. Li abbiamo fatti partecipare ai corsi per la patente europea!

È vero, hanno partecipato a dei corsi. È vero, le scuole riversano parte del fondo d'istituto (ricordate che c'è l'autonomia scolastica, parte dei soldi usati in una scuola vengono dal ministero, parte da iniziative della scuola stessa, ma alla fine è la scuola a decidere come e dove spenderli) per mantenere aggiornato il parco macchine e il parco risorse umane.

Ciò che non passa è la "cultura dello standard". Se è vero, come diceva se non erro il buon Tanenbaum che il bello degli standard è che ce ne sono tanti tra cui scegliere, una volta che ti affacci sulla rete, dovrebbe esistere solo il w3.org.

Chi è il colpevole di tutto ciò?

Innanzitutto il webmaster, o presunto tale. Io so chi è, ma non ve lo dico: seguite le briciole come Pollicino e fate 2+2. Certo, non richiedo che un insegnante, magari armato della più ampia scorta di buona volontà, metta in piedi un servizio che possa competere con quelli professionali, ma almeno, visto che siamo quasi nel 2007, farsi arrivare alle orecchie la voce che usare "questo sito è ottimizzato per Microsoft Internet Explorer" non è più di moda...

In secondo luogo, e non vedo perché non metterla in mezzo quando c'entra, la Microsoft e i suoi tentativi di scardinare gli standard. Sono curioso di sapere se la Apple, con i suoi iWeb e Pages, ha inserito un qualche formato di pagina Web che può essere visualizzato solo con Safari, formato che magari racchiuda in un solo file testo e immagini, così da non far confrontare i suoi poveri e spaesati utenti con complessi concetti come "percorsi relativi". Eppure la Apple ha sempre fatto della semplicità d'uso uno dei suoi cavalli di battaglia.

Infine, e qui andiamo sulle chiacchiere da autobus, il Governo. Non un particolare Governo, quanto l'entità "chi ci sta sopra e ci guida o decide per noi". Se il povero webmaster è ignorante, nel senso che ignora gli standard, e se le imperscrutabili decisioni della sua vita lo hanno portato ad essere un frustato acquirente di Microsoft e non un fedele credente della Apple, in fin dei conti era quasi normale che finisse così (si sa, chi va con lo zoppo, impara a zoppicare). Cosa ha fatto l'entità Governo per evitare questa fine ignobile al povero webmaster? Non molto. Gli ha proposto dei corsi per prendere una patente, in cui ti ripropongono i programmi Microsoft. Ha avuto un rinforzo positivo, etologicamente parlando. Si è convinto che il suo essere "uno che di queste cose ci capisce" poteva portarlo ad un livello superiore, a gestire non solo un sito personale per fini, se vuoi, privati, ma il sito di una scuola (chissà se ne gestisce anche altri). Insomma, il vecchio "chi sa fa, chi non sa dirige, chi non sa neanche dirigere coordina".

Io spero che questo diventi un caso isolato e che la norma possa essere questa. Ma di certo non basta essere provincia autonoma, bisogna anche essere mentalmente liberi e aperti :-)