Dieci piccoli indiani

Il piccolo giornalista che è in me scalpita. Oddio, ci sono tante piccole cose in me che scalpitano, ma è sabato sera, sono stanco, ho mandato a fare in culo un po' chiunque, non ho niente da fare (e mi sa che non lo avrò per parecchi sabati) per cui scrivere un po' potrebbe essere d'aiuto.

Allora, il vostro affezionatissimo ha eseguito l'avanzamento (italianizzazione discutibile di upgrade, ma a me e a Milo non veniva in mente niente di meglio e ci serviva distinguere update da upgrade) a Gutsy Gibbon, ora che è in beta. Vediamo un po' di trovare 10 cose che non mi vanno a genio e che intendo cambiare.

1 - Icone Human

L'ho già detto, ma mi ripeto. A me le icone Human fanno pena. E non mi importa se Canonical Ltd. le ha fatte realizzare da un grande artista che lavora per Iconfactory. Non in toto, certo, ma alcune sono tutte "sfocate" (vedi undo/redo), altre semplicemente "brutte" (vedi new-document), altre totalmente inutili (vedi i simboli: perché hanno tutti il cerchietto?). Quasi tutte non seguono lo standard di Tango, che per verità all'epoca (dapper drake) non esisteva o non era così pervasivo in GNOME.

IMHO basterebbe chidere a qualche bravo disegnatore (Lapo, Ulisse, Andreas, Joseph, ma non Jimmac) di preparare un nuovo set di icone. Non ne servono tante, giusto quelle per le cartelle (nelle varianti folder, folder-open, folder-visiting e folder-remote) , quella per la home e quella per document-open (che deve richiamare folder). Poi, se proprio si vuole, si possono aggiungere quelle per il cestino, o per l'hard disk o altro. Ma aver customizzato le icone delle cartelle IMHO può bastare.

Dunque, primo cambiamento suggerito: cambiare tema delle icone e mettere GNOME, o Mist, o Crux.

2 - Rivestimento della scrivania

Se proprio color cacca deve essere, allora Elephant è molto più figo.

Giuro.

Se fossi in voi mi scaricherei anche Lion e Giraffe. Avrebbero fatto meglio a includerli.

3 - Applicazioni inutili

Nel menù Applicazioni ci sono due nuove voci: Applicazioni -> Altro -> Blocca schermo e Applicazioni -> Altro -> Logout

Magari è un refuso, ma ho due dubbi:

1. Ma non c'è già Sistema -> Termina sessione per fare il logout?
2. Se stanno lì per avere accesso diretto alla funzione di blocco schermo, non era meglio mantenere il layout originale del pannello (che, per chi conosce solo Ubuntu prevede tre voci Blocca schemo, Termina sessione e Arresta direttamente nel menù Sistema).

Anche qui, una rapida modifica al menù per non avere di mezzo queste cose inutili.

Update a quanto pare erano lì a causa di una installazione mai rimossa di gnome-main-menu (per intenderci, quella accozzaglia simil-pulsane-Star di Novell). Uff, così mi sballano i conti...

4 - Cartelle utente

Gutsy installa xdg-user-dirs con una fastidiosa (IMHO) personalizzazione: la cartella $DOWNLOAD è la scrivania. OK, è il comportamento predefinito di Firefox, ma chi è Firefox per decidere che è meglio così?

La scrivania in GNOME, e ancora più in Ubuntu che ha giustamente deciso di togliere le icone di home, computer e cestino, è il luogo dei documenti su cui si sta lavorando, quelli che quando fai il login ti vuoi vedere davanti. Se ti serve un documento che hai archiviato lo cerchi (con un fantasmagorico Tracker, finalmente usabile e rapido nell'indicizzazione iniziale).

Scaricare sulla scrivania significa riempirla di cose che devo spostare o eliminare al più presto se voglio continuare ad avere sottocchio i file che mi servono.

Per correggere questo comportamento, creare una cartella $HOME/Scaricati e modificare il file $HOME/.config/user-dirs.dirs (o /etc/xdg/user-dirs.defaults se per tutti gli utenti). Credo però che bisognerà modificare anche le preferenze di Firefox e/o di Epiphany.

5 - Applet sul pannello

Se va avanti così, tra 4 o cinque versioni il pannello superiore sarà completamente pieno. E completamente inutile.

Da destra verso sinistra abbiamo, nell'ordine:

• Pulsante Termina sessione
• Orologio, con data
• Volume
• Area di notifica, con per lo meno icona di NetworkManager (a cui si aggiungono, secondo evenienza, quella della batteria, l'avvio di software disponibile, IM, Rhythmbox, Bluetooth, e via discorrendo
• Deskbar
• Selettore utente

Io toglierei il pulsante, sposterei al suo posto Deskbar e invertirei l'area di notifica e il selettore utente (o toglierei anche quest'ultimo, se non vi serve; a che pro mostrarvi il vostro nome se non dovete switchare?). Il motivo è semplice: in questo modo la crescita dell'area di notifica non va ad influire sulla posizione delle altre applet.

6, 7, 8, 9, 10 - That's all folks

Andiamo, pensavate veramente che ci fossero 10 problemi così gravi e insormontabili?

PS attenzione, ricordate sempre che per avanzare da una versione all'altra di Ubuntu è necessario:

1. avere installata la versione (n - 1) e averla aggiornata
2. eseguire "update-manager -d" (per forzare l'avanzamento) - modificare a mano /etc/apt/sources.list e eseguire "apt-get upgrade" non funziona con Ubuntu.
   

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.

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

Chiedo il massimo della pena, signor presidente

Bisogna smetterla con questi tentativi anarcoidi ed eversivi di rovesciare le fondamento del nostro stato. Volete le prove? Ecco le prove.

Questo che vedere è l'aspetto del tema Glossy distribuito con GNOME.


Quest'altro è l'aspetto del tema Nodoka che sarà predefinito in Fedora.


Bene, ammettiamolo, sono diversi, un po' diversi. Di certo nel colore, un po' nei dettagli.

C'era però bisogno di fare un tema da zero? Oddio, da zero, leggete l'intervista a
Martin Sourada e scoprirete non solo il perché, ma anche che tale intraprendente giovanotto ha copiato, ebbene sì. copiato il codice a un noto sviluppatore e artista, italianissimo perdipiù, senza nemmeno chiedere.

Non vi va? Riassumo. Fedora, come tutti, applica delle personalizzazioni. Finora si era limitata alla grafica della schermata di login, allo splash screen, allo sfondo predefinito e a usare Mist come tema della icone (che cambia solo le icone delle cartelle e poco altro). Ma Fedora ha in cantiere un nuovo set di icone, Echo, molto dissimile dalle indicazioni di Tango. Contrasti, saturazioni, tavolozze, prospettiva, stile. Tutto diverso. Era necessario un nuovo aspetto anche per il tema delle GTK+.

Ma per 4 o cinque cose che non si potevano ottenere cambiando colori e dimensioni, era proprio necessario fare un tema da zero? E chi ha detto che Cimi non avrebbe apprezzato i cambiamenti e magari inclusi in upstream (Cimi, dimmi che non ti hanno contattato, sennò mi fai fare brutta lettura coi miei lettori)?

Per esempio, i cursori degli scroller di Nodoka non sono malaccio, così come i gradienti dei pulsanti (che sembrano un po' più vetrosi e tridimensionali, forse anche grazie alle due righe più chiare in basso, forse al contrasto col colore dello sfondo, chissà) e il gradiente sulle linguette non attive (guardandolo ora a confronto, quello di Glossy è in effetti un po' troppo netto, sopra chiaro sotto scuro, e appare brutto nello schede disposte di lato). Di certo l'ombretta sui pulsanti attivi è una pessima idea per l'allineamento con gli altri widget e la barra di avanzamento sembra terribilmente irreale.

Morale della storia, abbiamo un altro tema "molto più veloce" che non è poi molto dissimile da altri. Anche se non ho mai capito come si fa a dire (a parte usare dei gradienti che siano computazionalmente meno onerosi, quindi più semplici) che un tema è più veloce. Abbiamo una suite per provarli e stressarli?

Ovviamente analogo discorso vale anche per altre note distribuzioni libere, come Ubuntu e il suo tema Human. A propostito, Cimi, non è che hai per le mani un paio di colori (sfondo, evidenziato, suggerimento) da usare con Glossy per renderlo più "Human"? Io ho fatto qualche prova, ma non riesco a tirare fuori una coppia arancione/{sfondo} adatta :-(

Brand New World

Dovrei rispondere a un paio di email, ma visto che non ho mai avuto tempo/voglia di completare il post a tal proposito, direi di dargli la precedenza.

In più ora è ufficiale. Il nuovo sistema di Virtual File System di GNOME potrebbe atterrare tra sei mesi sui vostri affannati desktop.

Alexander "Capitano, oh mio capitano" Larsson ha appena richiesto di includere GIO e GVF tra i moduli proposti per la versione 2.22 di GNOME. Sì, lo so anche io che la 2.20 è ufficialmente uscita 5 giorni fa, ma che volete, i tempi dell'informatica sono questi. GNOME 2.20, che voi magari non avete neanche ancora provato, per altri è già superato.

Necessarie premesse

Come ogni report che si rispetti, è bene cominciare con calma, da principio e senza tralasciare nulla. Il che vuol dir che non posso dare per assunto che la differenza tra FS, VFS, GNOME-VFS sia nota, visto anche il casino che solitamente regna. Dunque:

• per FS (File System) si intende un metodo per memorizzare e organizzare file e i dati in essi contenuti. Nell'uso comune è FS sia il modello che l'implementazione (per esempio quando si parla del FS ext3, si può indicare sia la definizione astratta che l'implementazione fisica nell'hard disk che avete nel computer). Inoltre viene chiamato file system anche tutto ciò che risiede all'interno della directory radice nel proprio sistema - insomma, come casino iniziale non c'è affatto male
  
• per VFS (Virtual File System) si intende un livello di astrazione che permette di specificare una interfaccia tra un kernel e un file system ("reale"). Il virtual file system server per avere un solo metodo per compiere la stessa operazione (per esempio leggi) indipendentemente dal supporto su cui la si esegue (hard disk con GNU/Linux, hard disk con Windoze, CD-ROM, DVD...)
  
• lo gnome-vfs infine è anch'esso un livello di astrazione, che però non si pone tra il kernel e i dispositivi reali, ma tra l'userspace e l'applicazione di GNOME e che fornisce anche un certo numero di funzionalità non previste (e spesso del tutto estranee) al VFS, come ad esempio l'identificazione del tipo MIME e dell'applicazione che gestisce un certo tipo di file oppure l'accesso tipo-filesystem a cose che file system non sono oppure ancora la risoluzione di nomi di host.
  

Spero di aver chiarito come i tre layer si occupino di cose distinte. Oh, non dimenticate che lo gnome-vfs deve poter funzionare su kernel e sistemi operativi diversi, per cui è normale che vada a ridefinite alcune porzioni già presenti nel VFS.

Lo spettro del passato

L'attuale gnome-vfs ha sulle spalle 8 anni di utilizzo, rifinitura e migliorie. In realtà quello che spesso si nota di più sono le limitazioni e i problemi che presenta :-(

Proprio dal lungo elenco di questi problemi è partito Alexander Larsson ormai un anno fa:

• compatibilità assente - nell'ottica di interoperabilità tra i vari desktop environment, gnome-vfs è limitato al solo ambiente GNOME (senza scomodare altri sistemi operativi, KDE usa un proprio vfs praticamente incompatibile) e alle sole applicazioni che lo usano esplicitamente (notare che le applicazioni GTK-only non traggono alcun beneficio dalla presenza di gnome-vfs; un esempio dovrebbe essere la versione Linux di Acrobat Reader)
  
• supporto ai DisplayNames assente - non mi ricordo più che cavolo fosse, quando scrissi questa parte....
  
• supporto per le icone assente - già, sembra strano, ma essendo gnome-vfs svincolato per design da qualsivoglia toolkit grafico, al momento la scelta dell'icona da mostrare per un determinato tipo di file è demandata all'applicazione; questo comporta il non ottimale (e magari non esente da errori) ripetersi di codice per stabilire l'icona per un file nelle applicazioni.
  
• astrazione vincolata dal modello POSIX - sempre per design, gnome-vfs è stato progettato in modo da basarsi su un'astrazione simile a quella del modello POSIX (nel senso, credo di FHS, ma anche di read() e write()); tale astrazione ha mostrato nel corso del tempo i suoi limiti, primo tra tutti il seppur ottimo modello POSIX mal si presta a operazioni di alto livello sui "file documento utente" perché basato sulla distinzione dei file in file di configurazione, file di sistema, file di dati della applicazioni; il gnome-vfs invece opera per lo più su file che l'utente vuole aprire, leggere, spostare, copiare, insomma file che l'utente manipola direttamente nelle attività di tutti i giorni con un'astrazione a livello superiore. Allo stesso tempo basandosi sul modello POSIX, l'implementazione dei moduli dello gnome-vfs diventa problematica (esempio: seeking durante la scrittura su webdav, poichè webdav funziona in modo molto differente dal modello POSIX)
  
• framework di autenticazione - se avete mai avuto a che fare con i dialoghi di autenticazione quando tentate di accedere a una risorsa (remota) per la quale è necessaria una password, sapete quanto la cosa sia al momento arzigogolata.
• URI specifici di gnome-vfs - per identificare i file, gnome-vfs usa delle particolare stringhe dette "URI di gnome-vfs", per esempio file:///home/luca/file.txt. Oltre a seguire uno standard proprio (vedi problema #1), oltre ad avere una serie di problemi di escaping di tali stringhe (pensati ai nome di file con spazi e a come sono gestiti su diversi backend [fs reale, samba, webdav...] gestiti da gnome-vfs), l'aver definito URI queste entità ha spesso creato la falsa convinzione che gnome-vfs fosse progettato per gestire in toto gli URI di tipo web, con conseguente supporto ai link mailto: ed header http extra
  
• enorme numero di librerie esterne - gconf, ORBit, avahi, hal, dbus, popt, libxml, kerberos, openssl, libz, libresolv, fuse, samba, selinux... nel corso degli anni si è accumultato in gnome-vfs una serie di funzioni molto spesso non necessarie alle applicazioni, o meglio necessarie solo a poche applicazioni. Non si tratta di funzioni inutili, certo, ma di funzioni che andrebbero spostate altrove
  
• asincronicità delle operazioni - anche qui i problemi sono parecchi, primo tra i quali l'annullamento di una operazione asincrona
• varie ed eventuali - un esempio per tutti, vicino a quella che è l'esperienza giornaliera dell'uso di GNOME: un dialogo standard per l'avanzamento delle operazioni di copia/spostamento
  

Mi rendo conto che si tratta di un elenco di problemi più che altro tecnici e di design della libreria, lontani in fondo dall'uso quotidiano.

Se però non capite come mai non vi riesca di elencare tutte le risorse condivise via SAMBA o accedere a qualcuna di esse con GNOME, allora il problema è sicuramente in uno dei punti precedenti :-)

Nota: se in questa sezione avete letto qualche stronzata, è perché l'ho platealmente copiaincollata da un post mai pubblicato aggiornato l'ultima volta a dicembre 2006.

La luce alla fine del tunnel

Per la verità GIO e GVF erano disponibili già da qualche tempo in alcuni repository privati di Alex; da una settimana o lo sviluppo si era ufficialmente spostato sul repository SVN di GNOME. In simile data Alex aveva dato luce a un branch di sviluppo di Nautilus in cui gnome-vfs sarebbe stato sostituito da gio.

Con un messaggio in lista, fa il punto della situazione, dichiarando che forse è possibile includere GIO e GVF nella 2.22.

Di cosa si tratta esattamente? Dunque:

• gio - è una libreria basata su gobject che fornisce un'astrazione per diverse forme di Input/Output. In futuro dovrebbe essere inclusa direttamente in glib.
  
• gvfs - è una delle implimentazioni possibili di gio, in particolare quella che va a fornire il "vfs in userspace" simile a quello di gnome-vfs

Chiaro, no? No?!? Allora provo a tradurre un po' di più il messaggio di Alex

Astraimi il flusso

Dire in poche parole cosa è GIO non è facile, specie se voglio fare il divulgatore. Stando alle parole di Alex, al momento GIO include le seguenti funzionalità:

• Classi di base per gli stream di input e output - beh, se è un'API per consentire di effettuare l'I/O direi che una cosa del genere ci deve stare per forza, no?
• Implementazione concreta di alcuni stream - file locali, socket e buffer di memoria
• GFile - una astrazione di "filename", ossia un oggetto che rappresenta qualcosa simile a un percorso di nome di file, ma con in più la caratteristica di poter essere esteso in modo da rappresentare anche gli URI o qualcosa di completamente diverso (come dicevano i Monty Python). Nella pratica dovrebbe essere ciò a cui si appoggeranno le applicazioni per compiere le varie operazioni su file, ovunque essi si trovino
• Una implementazione di GFile per i file locali
• API varie per la gestione dei file, tra cui: annullamento di operazioni di I/O, tipi di contenuto (MIME?), icone, legame tipomime <-> applicazione che lo gestisce, monitoraggio di volumi, file e directory.

Ora, se voi siete sviluppatori e avete a che fare con problemi inerenti l'apertura, il salvataggio, lo spostamento o ogni altra azione che vi può venire in mente relative ai file, allora GIO è quella porzione del futuro GNOME Desktop in cui cercare la funzione che vi serve.

Notare come GIO sia un'astrazione, nel senso che, a parte l'ovvia implementazione relativa ai file locali, offre solo i metodi che gli sviluppatori andranno a invocare (o evocare), non i dettagli relativi ai singoli casi. Riprendendo l'esempio di Acrobat Reader, la Adobe potrà in futuro usare GIO (in particolare la porzione GFile) per le operazioni di apertura e salvataggio di file, l'utente di Reader potrà aprire o salvare file in locale o in remoto in funzione delle implementazioni presenti nel sistema in uso. Figo, no?

Ovviamente le singole implementazioni sono dei moduli, e con questo arriviamo a...

Implementami il virtuale

...GVF, ossia una implementazione di GIO che fornisce quel "vfs in userspace" simile all'attuale gnome-vfs.

Sempre traducendo l'email di Alex, attualmente le seguenti porzioni sono disponibili in gvfs:

• Una libreria client - un GModule che viene caricato da GIO e che implementa GFile e altra roba richiesta per consentire l'accesso e la manipolazione dei file. Tale libreria fa uso di DBUS per chiedere al demone (vedi punto successivo) in protocollo di I/O necessario
• Un demone gfvs principale - collegato alla sessione, tiene traccia di tutte le posizione montate e consente di montarne di nuove
• Un'orda di demoni di mount - ciascuna posizione montata è gestira da un demone separato (previene da instabilità reciproca dei vari demoni)
• FUSE - sì. come poteva mancare un supporto a FUSE? Ah, supporto a FUSE nel senso che le applicazioni che non fanno uso di GIO possono accedere via FUSE ai filesystem montati da GIO. Nel senso inverso... beh, scrivetevi un modulo!
  

La luce alla fine del tunnel

L'elenco (sterile, lo so) di caratteristiche forse non può dire molto. Allora metto su il berrettino da entusiasta[1] e dichiaro quanto segue.

GIO+GVFS non è la soluzione a spinosi problemi che affliggono l'intera umanità, cose come la fame nel mondo o il proliferare della armi da fuoco.

GIO+GVFS è una porzione del futuro GNOME Desktop e Piattaforma di sviluppo (quando GIO verrà incluso in glib) che, nelle intenzioni:

1. renderà più "snello" lo GNOME Desktop
2. renderà più facile per gli sviluppatori che scrivono codice per GNOME o anche solo per GTK+ produrre software che vada a mettere mano (o piede) su dei file (locali, remoti, astratti o altro che siano)
3. dovrebbe rendere meno problematico l'uso di file non locali e/o non reali agli utenti finali (anche se, ricordiamolo, l'utente principale di GIO è lo sviluppatore)
   

Tutto il resto è solo chiacchiere e distintivo.

Specie se le applicazioni che al momento usano per motivi diversi gnome-vfs per le operazioni su file non migrano a GIO+GVFS o se non si scrivono nuovi moduli :-)

[1] nella accezione che il noto psicologo/psichiatra/psiqualcosa Alberoni da nel suo bellissimo libro "L'ottimismo", ossia di quella persona che è al di là del pessimista e dell'ottimista, una sorta di imbonitore e trascinatore di folle umane...

Blow Up

Ohi! Ho notato un paio di cose incredibili!!!!!

Provate a fare così: aprite il vostro browser web preferito e andata alla pagina http://www.gnome.org/start/2.20/notes/en/ poi scrollate un po' verso il basso, trovate una riga che dice "These 2.20 release notes are available in several languages" poco oltre c'è scritto "Italian", fate clic su "Italian". Come per magia la pagina si traduce in italiano!!!

Ma non è finito qui.

Se scrorrete verso il basso la pagina tradotta, trovate a un certo punto una schermata in cui si vede una finestra in cui un tizio sta scrivendo un'email. Se leggete il testo dell'email (se avete il programma in questione nella versione indicata) troverete che quelle indicazioni sono reali!!

Scrorrendo ancora verso il basso c'è un'altra schermata: il tizio che l'ha scattata (che io no so proprio chi sia... che nome è Beta Tester... uno pseudonimo... di certo è un hacker di quelli coi controfiocchi se riesce a usare un nome falso nelle email), dicevo, il tizio che l'ha scattata conosce Asia Argento! Ho controllato su Internet e la data del compleanno corrisponde!!!

Ah, dico che è un hacker perché più sotto, in un'altra schermata, sta compilando un modulo per partecipare a una festa di compleanno usando un nome falso: Stefano Belisario. Stefano Belisario, sempre stando a Internet, che dice solo cose vere. è un cantante con la voce di merda, come quella che canta, che è passato a fare il pornografico. Un'ottimo modo per un hacker di imbucarsi a una festa portando solo i dischi...

A meno che... Oh mio zio! Non è un hacker, ha conoscenze molto molto in alto! Non mi stupirei se avesse anche un robot gigante dal nome Ratzinga...

Questo post idiota sulle schermate e sulla loro percezione, scritto di fretta tra l'altro, è dedicato a chi redige i palinsenti delle emittenti non criptate, non a pagamento e non-un-sacco-di-altre-cose per aver aspettato (a mia memoria) che Ingmar Bergman e Michelangelo Antonioni morissero per mettere in onda dei loro film, nello specifico Fanny e Alexander del primo e Zabriskie Point e Blow-Up del secondo, peraltro uno dopo l'altro. Se fossi in voi terrei d'occhio Monicelli, pare abbia detto: "Bergman è morto, Monicelli è morto e anch'io non mi sento molto bene".

Ripensamenti

Per chiunque fosse rimasso scosso dal post di ieri, segnalo, fresco di scoperta causa ritardato completamente traduzione:

/apps/eog/view/scroll_wheel_zoom

E chi ha orecchie per intendere, intenda...

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

Tapparella

Prima di tutto:

Visto che siamo in clima di roventi polemiche contro la mediocrità (e di citazioni eliche per conto mio), cito le seguenti conclusioni:

[...] Quindi, in mezzo alle celebrazioni, sarebbe una buona idea per i promotori di Gnome fermarsi a pensare a cosa avrebbero potuto realizzare se avessero unito le forze con il concorrente Kde e dunque se ci fosse stato un unico progetto comune. Ne avrebbe giovato tutto il mondo Open Source, avendo una alternativa ancora migliore da contrapporre ai sistemi Microsoft. - da TuxJournal.net

Ma mi faccia il piacere!

Dunque la catena di pensieri è (il corsivo è mio, ovviamente):

• GNOME (ah, notare GNOME non Gnome) ha ormai dieci anni
• è nato perché le QT non erano libere, ma le QT ora sono libere e sono sempre state un passo avanti
  
• tutti parlano di KDE 4 e nessuno è andato alla festa di GNOME (io ho portato i dischi ma non mi hanno fatto entrare)
• Torvald ha fatto una delle sue (cicliche) uscite a cacchio dicendo che GNOME è una merda (perché non si poteva configurare il comporamento del clic centrale sulla barra del titolo, faccio presente, opzione immancabile e necessaria a tutti gli utenti, tant'è che io stesso la modifico 4 o 5 volte al giorno ora che c'è)
  
• Volkerding ha smesso 4 anni fa di impacchettare GNOME perché non riusciva a metterlo sotto /opt/gnome (e la colpa era _solo_ di GNOME visto che allora pkg-config era in mente dei)
  
• solo il fatto di essersi legato a Ubuntu ha tenuto a galla GNOME e solo perché il ciclo di rilasci avviene nello stesso periodo (io ho capito questo leggendo... ma RedHat/Fedora dove la mettiamo? e poi non è Ubuntu che si è legato a GNOME, semmai?)

Stabilito tutto ciò, decretiamo: "i promotori" di GNOME dovrebbero cospargersi il capo di cenere, flagellarsi, autolesionarsi e ammettere che KDE sarebbe ora molto meglio di ogni altra cosa immaginabile se loro non avessero perso tempo e fatto perdere risorse e visibilità a KDE.

Io comincerei, ma qualcuno mi spiega prima:

• perché il fatto che KDE sia un progetto europeo rappresenta uno svantaggio? Se fosse stato cinese cosa avrebbe avuto, l'embargo?
  
• perché non dovrebbero essere "i promotori" di KDE a cospargersi il capo di cenere , compiere tutte quelle azioni stupide prima elencate e innalzare al cielo lamentele tipo: "cazzo, sono dieci anni che produciamo un ambiente desktop nella sostanza migliore eppure abbiamo molta poca visibità, guarda cosa è successo con Ubuntu! Chissà cosa avremmo potuto realizzare se fossimo confluiti in GNOME"[1]
• perché gli illuminati "promotori" di KDE stanno ricreando un loro compositing manager (se non erro) visto che c'è già Compiz?
• perché le necessità di Linus Torvalds dovrebbero essere quelle di un normale utente come Mia Madre o Mia Sorella? Ho delle famose sviluppatrici di kernel per ambienti UNIX liberi in casa e non me ne sono accorto?
  

PS ma dire qualcosa tipo "Oh, sono dieci anni che il progetto GNOME esiste, lunga vita al progetto GNOME e speriamo che risolva presto i problemi che lo affliggono" sembrava troppo poco da fine intenditore di ambienti desktop moderni e funzionali?

[1] io 'ste storie unilaterali tipo "chi va con lo zoppo impara a zoppicare" non l'ho mai capite. Cioè, se io esco con Paris Hilton, divento io deficiente o lei nichilista scettica con tendenze minimaliste? Se divento amico di Rocco Siffredi mi si alluga a me o si accorcia a lui???

Quiz d'intelligenza

Quante righe bisogna cambiare (aggiungere E rimuovere) per avere il rubberbanding in Nautilus?

A) più di 100
B) più di 50
C) più di 20
D) più di 10
E) meno di 10

Domani mattina la risposta....

---- Update ---

È già mattina. Allora, la risposta esatta è 17. Complimenti a Emmanuele... anche se secondo me ha barato e ha sfruttato le sue conoscenze tra gli sviluppatori di Nautilus per avere informazioni confidenziali.Cose del genere in aziende serie come Apple Inc. non accadrebbero...

Ora debbo solo capire se la futura versione in cui la cosa potrebbe comparire la 2.20.1 oppure la 2.21.0 (mai che mi ricordi cosa si rilasci alla fine del freeze).

Per Cimi: il rubberbanding è una cosa molto semplice che tanti problemi da ai poveri traduttori. In pratica si tratta di quel rettangolo di selezione che trascinando si estende intorno agli elementi, selezionandoli. Ossia, in atre parole, quello che appare quando fai clic e trascini a partire da un punto non occupato da icone nella finestra del file manager. Pare che sia una mancanza non averlo anche nella vista a elenco, anche se, avendolo, bisogna un po' riabituarsi: per trascinare un elemento con il rubberbanding nella vista a elenco bisogno prima farci clic per selezionarlo, poi rifare clic-and-hold per trascinarlo, visto che se si fa subito clic-and-hold si fa partire il rubberbanding.

Oh, dimenticavo: l'obbligatoria schermata da sito di rumors.

Ho fatto le analisi, tutto a posto

Ah, il bello delle comunità.

No, non quel vago senso di promiscuità sessuale che contraddistingueva quei fottuti fricchettoni degli anni '70. Piuttosto quel senso di io faccio qualcosa, tu fai qualcosa, tutti facciamo qualcosa che avvantaggia anche gli altri quasi senza che ce ne rendiamo conto. Sì, forse avrei dovuto trovare un po' meno parole per descrivere un senso, ma non mi andava di ricorrere a qualche oscuro dialetto africano. Insomma, io al liceo mi sono dovuto leggere e studiare "La lingua tra norma e scelta"... ma che ve lo spiego a fa' lo strutturalismo di De Saussure (si pronuncia "desussurhrh")... vabbè, magari pensate ai Rammstein e capite cosa è lo strutturalismo.

Prendiamo a esempio il mio caso. Io volevo solo che le note di rilascio, anzi che la traduzione italiana delle note di GNOME 2.20 fosse veramente figa, con delle belle schermate autoesplicative e raffinate. Volevo che il PDF con form mostrato in Evince fosse in italiano, perbacco. E invece no. Avevo il PDF, gentilmente offerto, ma non riuscivo a modificare i form. Provavo, riprovavo, ricompilavo, riceckoutavo. Niente. Ho scritto alla mail list. Ho ricevuto risposta in 19 minuti. Modifiche dell'ultim'ora (cazzo, ma si possono mettere due elisioni di seguito?) causa versione da cui dipendere, messe lì e poi dimenticate: ci saremmo trovato un Evince mozzo per colpa di un #ifdef.

Ve lo sareste trovato anche voi, grande maggioranza silenziosa che non ha facoltà di commit e non usa jhbuild.

E invece troverete, voi e tutti i voi nel mondo che non leggono queste pagine, un programma funzionale e funzionante, perché tanti piccoli ometti perdono qualche ora del loro tempo a fare stronzate dissociative e alienanti come catturare delle schermate per delle note di rilascio senza chiedere nulla altro che il riconoscimento del loro lavoro e altri ometti stanno lì ad ascoltare i problemi di quelli che non riescono a catturare le schermate e dicono "Oiboh! abbiamo un problema" e si ingegnano a porvi rimedio anche loro senza chiedere nulla altro che il riconoscimento del loro lavoro...

... ora che mi ci fate pensare: almeno ringraziate, bastardi!

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.