Copiare è un'arte

Ciao, questo è il Mac.

nessun computer reale è stato infestato per scattare questa immagine

Questo, questo invece sarà GNOME.

as seen on current git snapshot

Sì, avete ragione: sono simili. Ma GNOME è meglio. È un design ispirato al Mac, rielaborato e sublimato, inserendo elementi e togliendone altri.

Vedete per esempio quei due pulsanti + (Aggiungi) e – (Rimuovi) in fondo all'elenco sulla destra di Mac? Inutili e ridondanti. A che servono? A chi servono? Forse a te, che vuoi mettere come sequenza le foto più adorabili del tuo adorabile micino? O a te, novella mamma che non staccheresti gli occhi dal tuo frugoletto? O magari ancora a te patito dello sci d'altura che intendi tappezzarlo con immagini dei tuoi campioni preferiti?

Ahi servo utente, di dolore ostello. Con questi tuoi pensieri ferisci il povero designer di GNOME, che ha previsto per te una cosa ben precisa. Le immagini personali che vuoi mettere sullo sfondo della scrivania devono essere collocate in $XDG_PICTURES_DIR (a.k.a. la cartella Immagini nella home per i non anglofoni). Punto. Fine. Stop. Niet. Nada. Nisba. Cuidado con los carteristas.

Altro che Mac, altro che aggiungere le singole cartelle sparse in ogni dove nel file system (e forse anche remote, dovrei provare) con i due pulsanti + (Aggiungi) e – (Rimuovi). Una sola singola posizione. Facile, semplice, immediato. A prova di utente.

...

...

Nel senso che nessuno lo userà mai perché nel frattempo sono tutti passati a Mac.

PS il primo che commenta "la prima cosa che l'utente cambia è lo sfondo" vado lì e gli stacco le braccine
PPS ovviamente grazie all'ispiratore del titolo del post :P

Dalla padella alla brace

Noi di Repubblica siamo sbarcati con voi su un pianeta nuovo e l'orizzonte è emozionante e infinito. Guardate come sa essere ironica e dispettosa la storia: nel momento in cui in Italia si cerca di imbavagliare l'informazione, il nostro giornale atterra per primo su un pianeta di pochi centimetri quadrati dove la libertà è senza limiti. Repubblica è su iPad, sulla "tavoletta" magica che sarà soltanto la prima creatura fra le molte che seguiranno e imiteranno l'intuizione di Steve Jobs, del nuovo modo di leggere e di essere liberi di informarsi. Come disse Sandro Pertini nelle sue indimenticabili parole al terzo gol dell'Italia mondiale in Spagna: "Adesso non ci prendono più". Ci proveranno, ma sarà sempre più difficile che ci riescano.

From here.

Mi verrebbe da dire "Complimenti a Vittorio Zucconi per non averci capito un ca##o", ma ho firmato un codice di condotta e bla bla bla, per cui, semplicemente, pacatamente, mi limito a puntualizzare che in quel piccolo pianeta ce ne sono tanti, ma tanti, di limiti.

Perché, se veramente pensate di continuare così, non gli serve provare a ingabbiarvi, ci sono già riusciti, non gli serve imbavagliarvi, vi siete già mozzati le ali da soli, miei piccoli uccelli di Hermes.

I Fought the Law

Ora spacco le pietre sotto il sole cocente.
Ho combattuto la legge... e la legge ha vinto (x2)
Ho comprato un dispositivo elettronico cinese perché costava meno
Ho combattuto la legge... e la legge ha vinto (x2)

Sono un fuorilegge. Il colore (e l'accostamento) dei colori del dispositivo elettronico noto come "Il cellulare di Luca" viola un brevetto. Sono un fuorilegge.

...io lo sapevo che dovevo comprarlo rosa

Dolcetto o scherzetto? - reprise

OK, la funzione di Empathy indicata nel post precedente non è tutta sta gran meraviglia, utile ma di certo non definitiva.

Ma si sa che sono sempre in vena di schermi, sono un tipo che si schermisce molto...

La vera notizia che volevo dare è la seguente. Voi, laggiù, proprio voi. Fate come me, non rinunciate ad avere un iTavoletta solo perché è closed source. Costruitevene uno da soli!

De lege grafica (Contra Steve)

Ho peccato. Ho riavviato il computer e dal menù di GRUB ho scelto "Windows XP Professional". Non l'ho fatto perché dovevo, o perché me l'avevano chiesto. L'ho fatto per provare piacere; piacere intellettuale, ma sempre piacere.


Ci sono solo due cose che mi causano una bella scarica di endorfina: una è sapere cose nuove, la seconda è... è... ah, no, sono tre, la terza è la nutella.

Io scopro, io so e sono felice. Sant'Agostino forse potrebbe capire. Di certo non capirebbe il pastore tedesco più amato d'Italia (no, non il commissario Rex, ma Ratzinga [no, non il robot gigante di Ratman {no, non volevo dire Batman, ma proprio Ratman}]). Ma ormai è cosa fatta. Stanotte farò doppi turni col mio cilicio. Fortuna che non c'è nutella in casa.


Ho scaricato software proprietario da www.apple.com

Di più.

Ho installato software proprietario scaricato da www.apple.com

Non basta.

Ho mandato in esecuzione software proprietario installato dopo averlo scaricato da www.apple.com

E la cosa mi è piaciuta.


Parliamoci seriamente. Apple è innovativa. Apple è visivamente appagante. Apple sa cosa vuole dire coerenza grafica e perché è importante.

Apple ha fatto una cosa molto intelligente (oddio, la mia mente direbbe "una cappellata", ma un po' di autocensura non fa mai male, fortifica il carattere e ti prepara a quando starai sul punto di dire a qualcuno che è un colluso) durante il porting del proprio software su Windows: ne ha rilasciate 4 - quattro - e non solo tre di queste non hanno l'aspetto di applicazioni windows, ma nemmeno si somigliano l'un l'altra.

Volete le prove? Sono sparse qua e là sotto forma di miniature di immagini su cui cliccare per aprire l'immagine a dimensione completa.


Cose simili a questa qui a fianco.

Non era la Apple quella che ci teneva tanto all'omogeneità dell'ambiente al punto da impedire nelle API per MacOS la possibilità di creare applicazioni extra-toolkit?

Non erano gli utenti lassivi e lassisti di Windows a dire di non voler passare a GNU/Linux perché è complicato, perché ti cambia interfaccia, perché devi stare a reimparare tutto?

Dopo aver chiuso delle istanze di Skype, Gmail e del monitor della stampante che nemmeno so perché ci fossero, dopo aver aggionato versione dell'antivirus e del firewall, forse ho finalmente capito. È un errore di interpretazione. Cioè il pensare che il nostro lavoro di omogenificazione (wow) possa attrarre in futuro le persone di cui sopra.

Per loro la complicazione di GNOME (o KDE), la loro difficoltà, non è che è diverso da Windows, ma che tutte le applicazioni usano in modo (abbastanza) coerente lo stesso toolkit, cosa inconcepibile per persone abituate da anni a usare metafore, icone, disposizioni e toolkit diversi per ognuna delle 40 applicazioni che hanno installate.

Qui ci vuole vera innovazione! Qui ci vuole vero appagamento visivo! Vogliamo un'applicazione killer per il dekstop GNU/Linux? Ho la soluzione: posizionamento randomico dei widget all'interno della finesta, con accluso tema randomico dei widget stessi, magari che cambia a ogni esecuzione (o ogni tot secondi, a scelta dell'utente, perché è importante permettergli di cambiare questa impostazione, così come il numero di temi diversi da usare per ogni finestra). Che poi faccia qualcosa di utile o meglio di altre che già esistono non importa.

Se poi implementiamo la cosa direttamente nelle GTK+ in modo da applicarlo a tutte le applicazioni in esecuzione, avremo il desktop più diversamente abile che si sia mai potuto immaginare.

Il toolkit è morto, viva il toolkit.

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

Erba voglio

Ora che è finalmente pubblico, possiamo dire come funziona Time Machine di Apple.

Dunque, per prima cosa serve un hard disk di backup. Magari esterno, magari su un altro Mac, magari condiviso tra diversi Mac, ma deve comunque essere un secondo hard disk. Niente backup su altri supporti.

In secondo luogo, da buona intelligenza artificiale che fa le cose al posto vostro, obbedisce a tre regole:

• mantenere backup orari delle ultime 24 ore
• mantenere backup giornalieri dell'ultimo mese
• mantenere backup settimanali finché il disco di backup non è pieno

Una volta pieno il disco di backup, ti avvisa e inizia a togliere di mezzo quelli più vecchi.

Per quanto riguarda il backup in sé e per sé, la prima volta viene effettuata una copia completa e senza compressione dell'intero contenuto dell'hard disk (esclusi file temporanei), nelle successive ovviamente una serie di backup incrementali. Il backup viene eseguito anche se il disco di destinazione non è collegato, ma viene memorizzato "in locale" e poi riversato sul disco di destinazione quando questo è collegato.

Che dire, come politica non è nulla di eclatantemente innovativo, solo è completamente automatizzato e preimpostato.

Il valore aggiunto è probabilmente nella grafica accattivante usata per navigare tra le vecchie versioni. Sarebbe interessante sapere se questa navigazione è permessa in tutte le applicazioni o se, molto più probabilmente, solo in alcune abilitate. Io penso proprio che è la seconda che ho detto, tant'è che la pagina su apple.com linkata all'inizio segnala solo iPhoto e Rubrica.

Ora, esclusa la parte "bling", che magari ci penserà Neil Patel dopo aver completato e pubblicato il suo prossimo progetto (sempre usando Clutter), quanto è difficile implementare quelle regole di backup e una GUI minimale per "Hardy Heron"?

Certo, ora che Mac OS ce l'ha predefinito, sarebbe la solita storia che l'opensource copia e via dicendo. Ma, francamente, ce ne può fottere qualcosa se il risultato è avere i dati degli utenti al sicuro e ripristinabili?

In fondo è per questo che esistono i computer, no? Mi compro un hard disk esterno, lo attacco, il computer mi chiede «Usare l'hard disk esterno appena collegato come destinazione di backup?» Io dico «Sì, grazie» e sono ragionevolmente sicuro che mi si mantiene in vita almeno una copia dei miei file, con il solo obbligo di attaccare ogni tanto quell'hard disk al computer.

Cestini criteriati

Mi ero dimenticato di aggiungere, nel precedente post, il collegamento alla pagina relativa alla gestione dei file eliminanti (Trash vs. Recycle Bin) su XvsXP.com

La cosa bella del confronto è che nessuno dei due contendenti, a parere di chi il confronto l'ha scritto, ha tutte e 4 le funzionalità richieste, ma solo 2. Il cestino ideale dovrebbe infatti permettere:

• l'esplorazione delle cartelle (OSX, Nautilus)
• l'eliminazione "sicura" (OSX)
• l'eliminazione individuale dei file (XP, Nautilus)
• il ripristino dei file cancellati nella posizione originale (XP)

Affascinante notare che il cestino di GNOME/Nautilus è un "ibrido" dei due.

Aderendo allo standard di fd.o, potrebbe diventare possibile avere il ripristino a basso costo (l'utente ha fatto clic su ripristina, leggi il valore la chiave che ti dice la posizione originale, sposta il file su tale valore) e arriveremmo così a 3 su 4.

Ma¹ non posso non domandarmi: GIO/GVFS è talmente avanti che magari in un prossimo futuro non dovrò più installare e usare srm(1) da terminale² per cancellare definitivamente i pornazzi file privati? Ci avrà pensato Alexander "Capitano, oh mio capitano" Larsson? In fondo GIO/GVFS è stato pensato per essere estensibile, no?

Mi sa che qui ci scappa un'email in mailing list.

[1] sì, lo so, non si dovrebbero cominciare le frasi con il "ma"...
[2] sì, lo so, potrei usare zenity per farmi uno script...

Crisi d'identità

Qualcuno è convinto che l'interfaccia del GIMP sia da cambiare. Che tutte quelle finestrelle che il GIMP apre sullo schermo danno fastidio. Che è meglio seguire Photoshop perché è meglio.

Io, sinceramente, non mi trovo così male con l'attuale interfaccia utente. Però in effetti, abbiamo dei seri problemi di... boh, direi corerenza, ma coerenza non è. Provo a spiegarmi.

E per farlo prendo a esempio due cosette. L'una è una applicazione simil-GIMP simil-Photoshop appena rilasciata per Mac, l'altro è il nostro vecchio caro GNOME Panel.

Partiamo dal secondo e da una riflessione fatta sulla desktop-devel-list di GNOME: ha senso avere 3 diversi elementi per gestire una applicazione? Prendete ad esempio Rhythmbox: posso avere un lanciatore sul pannello per mandarlo in esecuzione così, quando ci clicco sopra, mi compaiono un pulsante nell'applet Elenco finestre per mettere in primo piano o nascondere la finestra e un'icona nell'area di notifica (che forse non ci dovrebbe essere, ma questa è un'altra storia) per nascodere il tutto e per una gestione minimale della riproduzione. Analogo discorso si può fare per altre applicazioni come i vari client di IM, o lo stesso client email Evolution (che ora mostra un'icona lampeggiante all'arrivo di nuova posta).

Il tutto, per come è strutturato, è coerente: il lanciatore lancia, l'elenco finestre elenca e gestisce lo stato delle finestre, l'icona di notifica offre azioni e/o informazioni aggiuntive. Non è ammesso, o ammissibile, o cmq possibile, che un lanciatore informi sullo stato dell'applicazione o che uno dei pulsanti dell'elenco finestre abbia qualche voce extra relativa all'applicazione che rappresenta. Noi siamo puri e crediamo nella finestra come monade del nostro ambiente grafico. Una finestra, un pulsante. Per questo, ogni volta che apro N immagini in GIMP ho (almeno) N+2 finestre, quindi N+2 pulsanti. Ognuno per sé. Forse è questo che da fastidio...

Di contro in Mac OS (X) si ragiona per applicazioni: una applicazione, una icona nel dock. Un'icona nel dock che, di volta in volta, di momento in momento, serve per: lanciare una istanza dell'applicazione, portare in primo piano o nascondere un'istanza (in esecuzione) dell'applicazione, segnalare qualcosa (vedi l'icona del client email che mostra le nuove email o la nuova icona del client di calendario che indica la data odierna), fornire la possibilità di azioni aggiuntive (vedi i'icona di iTunes che funziona più o meno come l'icona di notifica di Rhythmbox). È un approccio migliore? Si? No? Non è detto. È un approccio diverso che in certe condizioni potrebbe risultare migliore. L'icona nel dock non è un lanciatore, o un segnaposto per la finestra o un indicatore. È l'applicazione stessa.

Poi ovviamente il dock ha una marea di altri problemi, ma almeno il fatto che a un'applicazione corrisponda una sola icona permette a menti non flessibili di creare un'identificazione chiara e ragionevole (Panfilo Maria Lippi direbbe venire in contro alle vostre limitate capacità mentali).

E qui arriviamo alla nuova applicazione simil-GIMP, simil-Photoshop per Mac annunciata prima. Si chiama Pixelmator, non è gratuita (se non ho capito male), non è libera (sebbene usi software open source, come dichiarato in homepage; credo si tratti di ImageMagik), quindi non ci dovrebbe interessare. Però un'occhiatina alle schermate e allo screencast mi rendono un po' invidioso... Non della tizia sdraiata sul divano rosa (semmai del divano rosa su cui la tizia è sdraiata), ma del fatto che Pixelmator sembra essere quello che è la mia idea di GIMP.

Guardate ad esempio questa anteprima. Le varie finestrelle sparse qua e là per la scrivania non hanno i canonici tre pulsanti ciascuna. Alcune hanno solo un pulsante "chiudi" (a che serve minimizzare o massimmizzare la finestra dei livelli o dei pennelli?), altre non hanno affatto pulsanti (come il dialogo Luminosità e contrasto: o applico le modifiche o le scarto. Ah. se vi guardate anche lo screencast, rodetevi dentro nel vedere come gli effetti sono applicati on-fly sull'immagine e OK serve solo da conferma). L'unica finestra che ha senso massimizzare o minimizzare è quella dell'immagine su cui sto lavorando. Suppongo, ma sono stato davanti a MacOSX una sola volta in vita mia per eseguire FireFox, che se nascondo l'applicazione nel dock, scompaiono tutte le finestrelle. Già che siamo in tema, godetevi anche la versione "schermo intero": direi che se sei un grafico e stai lavorando su una sola immagine in alta definizione non puoi chiedere di meglio no?

Su tutto regna indiscussa la barra dei menù unificata e spazialmente condivisa tra tutte le applicazioni, marchio di fabbrica del MacOS. Che sia cosa buona o meno io non lo so. So che, tanto tempo fa, quando ancora installavo GNOME e KDE, feci una settimana di test in KDE usando l'opzione che permette di avere una cosa analoga. Non mi stava molto simpatica: forse l'abitudine a un diverso approccio, forse il fatto che il KDE era pensato per avere la barra dei menù nella finestra e quello era solo un eye-candy, forse un sacco di altre cose. Di certo però l'approccio icona-applicazione nel dock richiede che la barra dei menù sia fatta in tal modo e viceversa. Le due scelte di design sono complementari.

OK, potreste dire che questo è un'altro di quei soliti post che vogliono spingere a uno GNOME sempre più simile a MacOS, fino ad essere una mera copia. Potreste dire che comunque una cosa del genere non è possibile perché GNOME deve fare i conti con X Window System, con gli altri toolkit, con gli standard e via dicendo. Potreste dire una marea di altre cose e vi dovrei anche dare ragione. Francamente però mi piacerebbe tanto avere una migliore gestione delle finestre nel mio ambiente grafico, ossia la possibilità di avere delle finestre toolbox e delle finestre dialogo/allerta che siano finalmente aderenti all'HIG: niente titolo e niente pulsanti per le finestre di entrambi (tranne chiudi per le toolbox). Se poi le toolbox "seguissero" la finestra madre quando viene minimizzata/ripristinata e non comparissero nell'elenco finestre, allora sarebbe il massimo.

E non vi verrebbe più in mente di chiedere un GIMP più simile a Photoshop.

PS - Sì, lo ammetto, il piccolo UI designer che è in me adora le toolbox e le metterebbe ovunque, anche in programmi tipo foglio di calcolo/word processor/presentazione. Per me è logica: finestra con documento e finestrelle con gli "strumenti" che si possono usare sul documento. Un paio di regole ben precise e un buon window manager e il gioco è fatto.

One more thing

Apple acquista CUPS....

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